grid_scores_ is due to be renamed at a minimum (because it's not always a
grid), and possibly restructured (e.g. because namedtuples aren't flexible
to optional additional fields). So I think this is somewhere we should not
be afraid to do the right thing in terms of design.


On 20 January 2014 14:54, Mathieu Blondel <notifications@github.com> wrote:

>  In sklearn/grid_search.py:
>
> > +
> > +            scores += curr_scores
> > +
> > +        if iid:
> > +            scores /= float(n_test_samples)
> > +        else:
> > +            scores /= float(n_folds)
> > +
> > +        for i in xrange(n_scorers):
> > +            # TODO: shall we also store the test_fold_sizes?
> > +            tup = _CVScoreTuple(parameters, scores[i], all_scores[i])
> > +            grid_scores[i].append(tup)
> > +
> > +    # Find the best parameters by comparing on the mean validation score:
> > +    # note that `sorted` is deterministic in the way it breaks ties
> > +    bests = [sorted(grid_scores[i], key=lambda x: x.mean_validation_score,
>
> I thought about this too. I think Python stores pointers to the
> _CVScoreTuple objects so memory-wise there shouldn't be too much
> overhead. And I was concerned with backward compatibility for attributes
> stored in GridSearchCV but I haven't given it much thoughts yet.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/scikit-learn/scikit-learn/pull/2759/files#r8996297>
> .
>