Question: [BUG] Optics float minsamples NN instantiation None yet. When passing minsamples as a float to optics l439 & 440 execute to bring it into integer ranges, but don't convert to int: When instantiating the NearestNeighbours class with a float it raises due to the float (l448). Error message: Fix: the int(...) is for backwards compatibbility to Python 2 where with T Number, while Python3 <!-- Please be aware that we are a loose team of volunteers so patience is necessary; assistance handling other issues is very welcome. We value all user contributions, no matter how minor they are. If we are slow to review, either the pull request needs some benchmarking, tinkering, convincing, etc. or more likely the reviewers are simply busy. In either case, we ask for your understanding during the review process. For more information, see our FAQ on this topic: http://scikit- Thanks for contributing! --

ordering : array, shape (n_samples,)         OPTICS ordered point indices (`ordering_`)     min_samples : int > 1 or float between 0 and 1 (default=None)    min_samples : int > 1 or float between 0 and 1         The same as the min_samples given to OPTICS. Up and down steep regions         can't have more then ``min_samples`` consecutive non-steep points.         Expressed as an absolute number or a fraction of the number of samples


Question: [BUG] Optics float minsamples NN instantiation None yet. When passing minsamples as a float to optics l439 & 440 execute to bring it into integer ranges, but don't convert to int: When instantiating the NearestNeighbours class with a float it raises due to the float (l448). Error message: Fix: the int(...) is for backwards compatibbility to Python 2 where with T Number, while Python3 <!-- Please be aware that we are a loose team of volunteers so patience is necessary; assistance handling other issues is very welcome. We value all user contributions, no matter how minor they are. If we are slow to review, either the pull request needs some benchmarking, tinkering, convincing, etc. or more likely the reviewers are simply busy. In either case, we ask for your understanding during the review process. For more information, see our FAQ on this topic: http://scikit- Thanks for contributing! --

n_samples = len(reachability)     _validate_size(min_samples, n_samples, 'min_samples')     if min_samples <= 1:        min_samples = max(2, min_samples * n_samples)        min_samples = max(2, int(min_samples * n_samples))     if min_cluster_size is None:         min_cluster_size = min_samples     _validate_size(min_cluster_size, n_samples, 'min_cluster_size')     if min_cluster_size <= 1:        min_cluster_size = max(2, min_cluster_size * n_samples)        min_cluster_size = max(2, int(min_cluster_size * n_samples))      clusters = _xi_cluster(reachability[ordering], predecessor[ordering],                            ordering, xi,


Question: [BUG] Optics float minsamples NN instantiation None yet. When passing minsamples as a float to optics l439 & 440 execute to bring it into integer ranges, but don't convert to int: When instantiating the NearestNeighbours class with a float it raises due to the float (l448). Error message: Fix: the int(...) is for backwards compatibbility to Python 2 where with T Number, while Python3 <!-- Please be aware that we are a loose team of volunteers so patience is necessary; assistance handling other issues is very welcome. We value all user contributions, no matter how minor they are. If we are slow to review, either the pull request needs some benchmarking, tinkering, convincing, etc. or more likely the reviewers are simply busy. In either case, we ask for your understanding during the review process. For more information, see our FAQ on this topic: http://scikit- Thanks for contributing! --

reachability plot is defined by the ratio from one point to its         successor being at most 1-xi.     min_samples : int > 1 or float between 0 and 1 (default=None)    min_samples : int > 1         The same as the min_samples given to OPTICS. Up and down steep regions         can't have more then ``min_samples`` consecutive non-steep points.        Expressed as an absolute number or a fraction of the number of samples        (rounded to be at least 2).     min_cluster_size : int > 1 or float between 0 and 1        Minimum number of samples in an OPTICS cluster, expressed as an        absolute number or a fraction of the number of samples (rounded        to be at least 2).    min_cluster_size : int > 1        Minimum number of samples in an OPTICS cluster.      predecessor_correction : bool         Correct clusters based on the calculated predecessors.


Question: Copy param ignored in TfidfVectorizer I was playing with vectorizers and I found this: However that parameter is not used later in the method. Here is used: Is there anything I am missing?

# we set copy to False         return self._tfidf.transform(X, copy=False)     def transform(self, raw_documents, copy=True):    def transform(self, raw_documents, copy="deprecated"):         """Transform documents to document-term matrix.          Uses the vocabulary and document frequencies (df) learned by fit (or


Question: Copy param ignored in TfidfVectorizer I was playing with vectorizers and I found this: However that parameter is not used later in the method. Here is used: Is there anything I am missing?

Whether to copy X and operate on the copy or perform in-place             operations. <ins>            .. deprecated:: 0.22               The `copy` parameter is unused and was deprecated in version               0.22 and will be removed in 0.24. This parameter will be               ignored.</ins>         Returns         -------         X : sparse matrix, [n_samples, n_features]


Question: Copy param ignored in TfidfVectorizer I was playing with vectorizers and I found this: However that parameter is not used later in the method. Here is used: Is there anything I am missing?

"""         check_is_fitted(self, '_tfidf', 'The tfidf vector is not fitted') <ins>        # FIXME Remove copy parameter support in 0.24        if copy != "deprecated":            msg = ("'copy' param is unused and has been deprecated since "                   "version 0.22. Backward compatibility for 'copy' will "                   "be removed in 0.24.")            warnings.warn(msg, DeprecationWarning)</ins>         X = super().transform(raw_documents)         return self._tfidf.transform(X, copy=False)


Question: RFC ColumnTransformer input validation and requirements There have been some issues around ColumnTransformer input requirements that I think we might want to discuss more explicitly. Examples are an actual bug when changing columns: and how to define number of input features . Related is also the idea of checking for column name consistency: Mainly I'm asking whether it makes sense to have the same requirements for ColumnTransformer as for other estimators. ColumnTransformer is the only estimator that addresses columns by name, and so reordering columns doesn't impact the model and actually everything works fine. Should we still aim for checking for reordering of columns? Right now, , which makes sense, since it only cares about the columns it is using. Should we allow that going forward as long as remainder is not used? (if remainder is used, the result of would have a different shape and downstream estimators would break, so I think we shouldn't support it in this case). In either case, what's ` or the number of columns actually used? Does it even make sense to define it if we allow adding other columns that are ignored?

# Author: Andreas Mueller #         Joris Van den Bossche # License: BSDimport warnings from itertools import chain import numbers import numpy as np from scipy import sparse from joblib import Parallel, delayed


Question: RFC ColumnTransformer input validation and requirements There have been some issues around ColumnTransformer input requirements that I think we might want to discuss more explicitly. Examples are an actual bug when changing columns: and how to define number of input features . Related is also the idea of checking for column name consistency: Mainly I'm asking whether it makes sense to have the same requirements for ColumnTransformer as for other estimators. ColumnTransformer is the only estimator that addresses columns by name, and so reordering columns doesn't impact the model and actually everything works fine. Should we still aim for checking for reordering of columns? Right now, , which makes sense, since it only cares about the columns it is using. Should we allow that going forward as long as remainder is not used? (if remainder is used, the result of would have a different shape and downstream estimators would break, so I think we shouldn't support it in this case). In either case, what's ` or the number of columns actually used? Does it even make sense to define it if we allow adding other columns that are ignored?

"The output of the '{0}' transformer should be 2D (scipy "                     "matrix, array, or pandas DataFrame).".format(name)) <ins>    def _validate_features(self, n_features, feature_names):        """Ensures feature counts and names are the same during fit and        transform.        TODO: It should raise an error from v0.24        """        if ((self._feature_names_in is None or feature_names is None)                and self._n_features == n_features):            return        neg_col_present = np.any([_is_negative_indexing(col)                                  for col in self._columns])        if neg_col_present and self._n_features != n_features:            raise RuntimeError("At least one negative column was used to "                               "indicate columns, and the new data's number "                               "of columns does not match the data given "                               "during fit. "                               "Please make sure the data during fit and "                               "transform have the same number of columns.")        if (self._n_features != n_features or                np.any(self._feature_names_in != np.asarray(feature_names))):            warnings.warn("Given feature/column names or counts do not match "                          "the ones for the data given during fit. This will "                          "fail from v0.24.",                          DeprecationWarning)</ins>     def _log_message(self, name, idx, total):         if not self.verbose:             return None


Question: RFC ColumnTransformer input validation and requirements There have been some issues around ColumnTransformer input requirements that I think we might want to discuss more explicitly. Examples are an actual bug when changing columns: and how to define number of input features . Related is also the idea of checking for column name consistency: Mainly I'm asking whether it makes sense to have the same requirements for ColumnTransformer as for other estimators. ColumnTransformer is the only estimator that addresses columns by name, and so reordering columns doesn't impact the model and actually everything works fine. Should we still aim for checking for reordering of columns? Right now, , which makes sense, since it only cares about the columns it is using. Should we allow that going forward as long as remainder is not used? (if remainder is used, the result of would have a different shape and downstream estimators would break, so I think we shouldn't support it in this case). In either case, what's ` or the number of columns actually used? Does it even make sense to define it if we allow adding other columns that are ignored?

sparse matrices.          """<ins>        # TODO: this should be `feature_names_in_` when we start having it        if hasattr(X, "columns"):            self._feature_names_in = np.asarray(X.columns)        else:            self._feature_names_in = None</ins>         X = _check_X(X)         self._validate_transformers()         self._validate_column_callables(X)


Question: RFC ColumnTransformer input validation and requirements There have been some issues around ColumnTransformer input requirements that I think we might want to discuss more explicitly. Examples are an actual bug when changing columns: and how to define number of input features . Related is also the idea of checking for column name consistency: Mainly I'm asking whether it makes sense to have the same requirements for ColumnTransformer as for other estimators. ColumnTransformer is the only estimator that addresses columns by name, and so reordering columns doesn't impact the model and actually everything works fine. Should we still aim for checking for reordering of columns? Right now, , which makes sense, since it only cares about the columns it is using. Should we allow that going forward as long as remainder is not used? (if remainder is used, the result of would have a different shape and downstream estimators would break, so I think we shouldn't support it in this case). In either case, what's ` or the number of columns actually used? Does it even make sense to define it if we allow adding other columns that are ignored?

"""         check_is_fitted(self, 'transformers_')         X = _check_X(X)<ins>        if hasattr(X, "columns"):            X_feature_names = np.asarray(X.columns)        else:            X_feature_names = None</ins>          if self._n_features > X.shape[1]:             raise ValueError('Number of features of the input must be equal '


Question: RFC ColumnTransformer input validation and requirements There have been some issues around ColumnTransformer input requirements that I think we might want to discuss more explicitly. Examples are an actual bug when changing columns: and how to define number of input features . Related is also the idea of checking for column name consistency: Mainly I'm asking whether it makes sense to have the same requirements for ColumnTransformer as for other estimators. ColumnTransformer is the only estimator that addresses columns by name, and so reordering columns doesn't impact the model and actually everything works fine. Should we still aim for checking for reordering of columns? Right now, , which makes sense, since it only cares about the columns it is using. Should we allow that going forward as long as remainder is not used? (if remainder is used, the result of would have a different shape and downstream estimators would break, so I think we shouldn't support it in this case). In either case, what's ` or the number of columns actually used? Does it even make sense to define it if we allow adding other columns that are ignored?

.format(self._n_features, X.shape[1]))          # No column reordering allowed for named cols combined with remainder<ins>        # TODO: remove this mechanism in 0.24, once we enforce strict column        # name order and count. See #14237 for details.</ins>         if (self._remainder[2] is not None and                 hasattr(self, '_df_columns') and                 hasattr(X, 'columns')):


Question: RFC ColumnTransformer input validation and requirements There have been some issues around ColumnTransformer input requirements that I think we might want to discuss more explicitly. Examples are an actual bug when changing columns: and how to define number of input features . Related is also the idea of checking for column name consistency: Mainly I'm asking whether it makes sense to have the same requirements for ColumnTransformer as for other estimators. ColumnTransformer is the only estimator that addresses columns by name, and so reordering columns doesn't impact the model and actually everything works fine. Should we still aim for checking for reordering of columns? Right now, , which makes sense, since it only cares about the columns it is using. Should we allow that going forward as long as remainder is not used? (if remainder is used, the result of would have a different shape and downstream estimators would break, so I think we shouldn't support it in this case). In either case, what's ` or the number of columns actually used? Does it even make sense to define it if we allow adding other columns that are ignored?

'and for transform when using the '                                  'remainder keyword') <ins>        self._validate_features(X.shape[1], X_feature_names)</ins>         Xs = self._fit_transform(X, None, _transform_one, fitted=True)         self._validate_output(Xs)


Question: RFC ColumnTransformer input validation and requirements There have been some issues around ColumnTransformer input requirements that I think we might want to discuss more explicitly. Examples are an actual bug when changing columns: and how to define number of input features . Related is also the idea of checking for column name consistency: Mainly I'm asking whether it makes sense to have the same requirements for ColumnTransformer as for other estimators. ColumnTransformer is the only estimator that addresses columns by name, and so reordering columns doesn't impact the model and actually everything works fine. Should we still aim for checking for reordering of columns? Right now, , which makes sense, since it only cares about the columns it is using. Should we allow that going forward as long as remainder is not used? (if remainder is used, the result of would have a different shape and downstream estimators would break, so I think we shouldn't support it in this case). In either case, what's ` or the number of columns actually used? Does it even make sense to define it if we allow adding other columns that are ignored?

remainder=remainder,                              sparse_threshold=sparse_threshold,                              verbose=verbose)<ins>def _is_negative_indexing(key):    # TODO: remove in v0.24    def is_neg(x): return isinstance(x, numbers.Integral) and x < 0    if isinstance(key, slice):        return is_neg(key.start) or is_neg(key.stop)    elif _check_key_type(key, int):        return np.any(np.asarray(key) < 0)    return False</ins>


Question: LassoCV always sets precompute to False before fitting the chosen alpha value I'm using a very large data-set. After fitting 100 x 3-fold cross-validated LASSOs at lightning speed (a few seconds total), LassoCV stalls at the final hurdle: fitting a LASSO with the chosen alpha value to the whole data-set (waiting over half an hour - it should only take approximately 50% longer than a single fold...). After a lot of head-scratching I found the reason why. In 's () just before calling the final () (line 1223 in Python2.7/sklearn0.19.0), there is the rather inconspicuous line So even if you've specified precompute as True when calling LassoCV, it is ignored. Why is this? It's making the computation impractically slow (should it even be this slow without precompute?) - literally just commenting the line out makes the fit instantaneous. Am I missing something here mathematically - I can't see anything wrong with using a precomputed Gram matrix for the final fit when it was used for all of the cross-validation fits? The implementation seems to imply it should be used for performance whenever numsamples num_features. Why hard set it to False?

model.alpha = best_alpha         model.l1_ratio = best_l1_ratio         model.copy_X = copy_X        model.precompute = False        precompute = getattr(self, "precompute", None)        if isinstance(precompute, str) and precompute == "auto":            model.precompute = False         model.fit(X, y)         if not hasattr(self, 'l1_ratio'):             del self.l1_ratio_


Question: AttributeError with crossvalpredict(method='predictproba') when using MultiOuputClassifier I believe there is a bug when using with a . I think the problem is in the use of here: To obtain the attribute of a , you need instead. If core team members have any idea of how to address this, I am happy to submit a patch. Array with prediction probabilities. System: python: 3.6.8 (default, Feb 21 2019, 18:30:04) [MSC v.1916 64 bit (AMD64)] executable: C:\Users\nak142\Miniconda3\envs\myo\ machine: Windows-10-10.0.-SP0 BLAS: macros: libdirs: cblas_libs: cblas Python deps: pip: 19.1.1 setuptools: 41.0.1 sklearn: 0.21.2 numpy: 1.16.4 scipy: 1.2.1 Cython: 0.29.12 pandas: 0.24.2

def __init__(self, estimator, n_jobs=None):         super().__init__(estimator, n_jobs) <ins>    def fit(self, X, Y, sample_weight=None):        """Fit the model to data matrix X and targets Y.        Parameters        ----------        X : {array-like, sparse matrix} of shape (n_samples, n_features)            The input data.        Y : array-like of shape (n_samples, n_classes)            The target values.        sample_weight : array-like of shape (n_samples,) or None            Sample weights. If None, then samples are equally weighted.            Only supported if the underlying classifier supports sample            weights.        Returns        -------        self : object        """        super().fit(X, Y, sample_weight)        self.classes_ = [estimator.classes_ for estimator in self.estimators_]        return self</ins>     def predict_proba(self, X):         """Probability estimates.         Returns prediction probabilities for each class of each output.


Question: AttributeError with crossvalpredict(method='predictproba') when using MultiOuputClassifier I believe there is a bug when using with a . I think the problem is in the use of here: To obtain the attribute of a , you need instead. If core team members have any idea of how to address this, I am happy to submit a patch. Array with prediction probabilities. System: python: 3.6.8 (default, Feb 21 2019, 18:30:04) [MSC v.1916 64 bit (AMD64)] executable: C:\Users\nak142\Miniconda3\envs\myo\ machine: Windows-10-10.0.-SP0 BLAS: macros: libdirs: cblas_libs: cblas Python deps: pip: 19.1.1 setuptools: 41.0.1 sklearn: 0.21.2 numpy: 1.16.4 scipy: 1.2.1 Cython: 0.29.12 pandas: 0.24.2

if self.order_ == 'random':                 self.order_ = random_state.permutation(Y.shape[1])         elif sorted(self.order_) != list(range(Y.shape[1])):                raise ValueError("invalid order")            raise ValueError("invalid order")          self.estimators_ = [clone(self.base_estimator)                             for _ in range(Y.shape[1])]


Question: StratifiedKFold makes fold-sizes very unequal I found this when trying to write tests for . Right now, `: We could achieve something like but our rounding doesn't let us :-/

Notes     -----    Train and test sizes may be different in each fold, with a difference of at    most ``n_classes``.    The implementation is designed to:    * Generate test sets such that all contain the same distribution of      classes, or as close as possible.    * Be invariant to class label: relabelling ``y = ["Happy", "Sad"]`` to      ``y = [1, 0]`` should not change the indices generated.    * Preserve order dependencies in the dataset ordering, when      ``shuffle=False``: all samples from class k in some test set were      contiguous in y, or separated in y by samples from classes other than k.    * Generate test sets where the smallest and largest differ by at most one      sample.    .. versionchanged:: 0.22        The previous implementation did not follow the last constraint.      See also     --------


Question: StratifiedKFold makes fold-sizes very unequal I found this when trying to write tests for . Right now, `: We could achieve something like but our rounding doesn't let us :-/

allowed_target_types, type_of_target_y))          y = column_or_1d(y)        n_samples = y.shape[0]        unique_y, y_inversed = np.unique(y, return_inverse=True)        y_counts = np.bincount(y_inversed)        _, y_idx, y_inv = np.unique(y, return_index=True, return_inverse=True)        # y_inv encodes y according to lexicographic order. We invert y_idx to        # map the classes so that they are encoded by order of appearance:        # 0 represents the first label appearing in y, 1 the second, etc.        _, class_perm = np.unique(y_idx, return_inverse=True)        y_encoded = class_perm[y_inv]        n_classes = len(y_idx)        y_counts = np.bincount(y_encoded)         min_groups = np.min(y_counts)         if np.all(self.n_splits > y_counts):             raise ValueError("n_splits=%d cannot be greater than the"


Question: StratifiedKFold makes fold-sizes very unequal I found this when trying to write tests for . Right now, `: We could achieve something like but our rounding doesn't let us :-/

% (self.n_splits))         if self.n_splits > min_groups:             warnings.warn(("The least populated class in y has only %d"                           " members, which is too few. The minimum"                           " number of members in any class cannot"                           " be less than n_splits=%d."                           % (min_groups, self.n_splits)), Warning)        # pre-assign each sample to a test fold index using individual KFold        # splitting strategies for each class so as to respect the balance of        # classes        # NOTE: Passing the data corresponding to ith class say X[y==class_i]        # will break when the data is not 100% stratifiable for all classes.        # So we pass np.zeroes(max(c, n_splits)) as data to the KFold        per_cls_cvs = [            KFold(self.n_splits, shuffle=self.shuffle,                  random_state=rng).split(np.zeros(max(count, self.n_splits)))            for count in y_counts]        test_folds = np.zeros(n_samples, dtype=np.int)        for test_fold_indices, per_cls_splits in enumerate(zip(*per_cls_cvs)):            for cls, (_, test_split) in zip(unique_y, per_cls_splits):                cls_test_folds = test_folds[y == cls]                # the test split can be too big because we used                # KFold(...).split(X[:max(c, n_splits)]) when data is not 100%                # stratifiable for all the classes                # (we use a warning instead of raising an exception)                # If this is the case, let's trim it:                test_split = test_split[test_split < len(cls_test_folds)]                cls_test_folds[test_split] = test_fold_indices                test_folds[y == cls] = cls_test_folds                           " members, which is less than n_splits=%d."                           % (min_groups, self.n_splits)), UserWarning)        # Determine the optimal number of samples from each class in each fold,        # using round robin over the sorted y. (This can be done direct from        # counts, but that code is unreadable.)        y_order = np.sort(y_encoded)        allocation = np.asarray(            [np.bincount(y_order[i::self.n_splits], minlength=n_classes)             for i in range(self.n_splits)])        # To maintain the data order dependencies as best as possible within        # the stratification constraint, we assign samples from each class in        # blocks (and then mess that up when shuffle=True).        test_folds = np.empty(len(y), dtype='i')        for k in range(n_classes):            # since the kth column of allocation stores the number of samples            # of class k in each test set, this generates blocks of fold            # indices corresponding to the allocation for class k.            folds_for_class = np.arange(self.n_splits).repeat(allocation[:, k])            if self.shuffle:                rng.shuffle(folds_for_class)            test_folds[y_encoded == k] = folds_for_class         return test_folds      def _iter_test_masks(self, X, y=None, groups=None):


Question: kernelapproximation.Nystroem does not support precomputed kernel The documentation says that precomputed kernels are supported in Nystroem, but in reality it does not seem to be the case: https://scikit- Example code: Leads to

sklearn.metrics.pairwise.kernel_metrics : List of built-in kernels.     """<ins></ins>     def __init__(self, kernel="rbf", gamma=None, coef0=None, degree=None,                  kernel_params=None, n_components=100, random_state=None):         self.kernel = kernel


Question: kernelapproximation.Nystroem does not support precomputed kernel The documentation says that precomputed kernels are supported in Nystroem, but in reality it does not seem to be the case: https://scikit- Example code: Leads to

params = self.kernel_params         if params is None:             params = {}        if not callable(self.kernel):        if not callable(self.kernel) and self.kernel != 'precomputed':             for param in (KERNEL_PARAMS[self.kernel]):                 if getattr(self, param) is not None:                     params[param] = getattr(self, param)


Question: kernelapproximation.Nystroem does not support precomputed kernel The documentation says that precomputed kernels are supported in Nystroem, but in reality it does not seem to be the case: https://scikit- Example code: Leads to

self.coef0 is not None or                     self.degree is not None):                 raise ValueError("Don't pass gamma, coef0 or degree to "                                 "Nystroem if using a callable kernel.")                                 "Nystroem if using a callable "                                 "or precomputed kernel")          return params


Question: HistGradientBoostingClassifier does not work with string target when early stopping turned on <!-- If your issue is a usage question, submit it here instead: StackOverflow with the scikit-learn tag: Mailing List: For more information, see User Questions: http://scikit- --<!-- Instructions For Filing a Bug: --<!-- Example: Joblib Error thrown when calling fit on LatentDirichletAllocation with evaluateevery 0--The scorer used under the hood during early stopping is provided with being integer while are original classes (i.e. string). We need to encode each time that we want to compute the score. <!-- Example: If the code is too long, feel free to put it in a public gist and link it in the issue: --No error is thrown <!-- Please paste or specifically describe the actual output or traceback. --Maybe one solution would be to do:

Scores are computed on validation data or on training data.         """        if is_classifier(self):            y_small_train = self.classes_[y_small_train.astype(int)]         self.train_score_.append(             self.scorer_(self, X_binned_small_train, y_small_train)         )          if self._use_validation_data:            if is_classifier(self):                y_val = self.classes_[y_val.astype(int)]             self.validation_score_.append(                 self.scorer_(self, X_binned_val, y_val)             )


Question: medianabsoluteerror multioutput Multioutput is not currently supported in . Is this a design choice or has it just not been implemented yet? In case of the latter, I am happy to submit a PR.

sample_weight, multioutput)  def median_absolute_error(y_true, y_pred):def median_absolute_error(y_true, y_pred, multioutput='uniform_average'):     """Median absolute error regression loss     Read more in the :ref:`User Guide <median_absolute_error>`.    Median absolute error output is non-negative floating point. The best value    is 0.0. Read more in the :ref:`User Guide <median_absolute_error>`.      Parameters     ----------    y_true : array-like of shape (n_samples,)    y_true : array-like of shape = (n_samples) or (n_samples, n_outputs)         Ground truth (correct) target values.     y_pred : array-like of shape (n_samples,)    y_pred : array-like of shape = (n_samples) or (n_samples, n_outputs)         Estimated target values.     multioutput : {'raw_values', 'uniform_average'} or array-like of shape        (n_outputs,)        Defines aggregating of multiple output values. Array-like value defines        weights used to average errors.        'raw_values' :            Returns a full set of errors in case of multioutput input.        'uniform_average' :            Errors of all outputs are averaged with uniform weight.     Returns     -------    loss : float        A positive floating point value (the best value is 0.0).    loss : float or ndarray of floats        If multioutput is 'raw_values', then mean absolute error is returned        for each output separately.        If multioutput is 'uniform_average' or an ndarray of weights, then the        weighted average of all output errors is returned.      Examples     --------


Question: medianabsoluteerror multioutput Multioutput is not currently supported in . Is this a design choice or has it just not been implemented yet? In case of the latter, I am happy to submit a PR.

>>> y_pred = [2.5, 0.0, 2, 8]     >>> median_absolute_error(y_true, y_pred)     0.5    >>> y_true = [[0.5, 1], [-1, 1], [7, -6]]    >>> y_pred = [[0, 2], [-1, 2], [8, -5]]    >>> median_absolute_error(y_true, y_pred)    0.75    >>> median_absolute_error(y_true, y_pred, multioutput='raw_values')    array([0.5, 1. ])    >>> median_absolute_error(y_true, y_pred, multioutput=[0.3, 0.7])    0.85      """    y_type, y_true, y_pred, _ = _check_reg_targets(y_true, y_pred, None)    if y_type == 'continuous-multioutput':        raise ValueError("Multioutput not supported in median_absolute_error")    return np.median(np.abs(y_pred - y_true))    y_type, y_true, y_pred, multioutput = _check_reg_targets(        y_true, y_pred, multioutput)    output_errors = np.median(np.abs(y_pred - y_true), axis=0)    if isinstance(multioutput, str):        if multioutput == 'raw_values':            return output_errors        elif multioutput == 'uniform_average':            # pass None as weights to np.average: uniform mean            multioutput = None    return np.average(output_errors, weights=multioutput)   def explained_variance_score(y_true, y_pred,


Question: datasets :: makeclassification() weights parameter should be a sequence (not just a list). If there is a pertinent reason that must be a list, while all other iterable parameters are arrays, then it should be mentioned in the docstring. Otherwise, the docstring should be amended as in , e.g. "weights : list of floats or None (default=None)" -"weights : sequence of floats or None (default=None)", along with amended lines 165 and 171 (see Corrections). Should not fail: as valid as a list: #wimlds [MRG] Added an example to the …or class <!-- Thanks for contributing a pull request! Please ensure you have taken a look at the contribution guidelines: --<!-- Contributes to . --I an example to the () <!-- Please be aware that we are a loose team of volunteers so patience is necessary; assistance handling other issues is very welcome. We value all user contributions, no matter how minor they are. If we are slow to review, either the pull request needs some benchmarking, tinkering, convincing, etc. or more likely the reviewers are simply busy. In either case, we ask for your understanding during the review process. For more information, see our FAQ on this topic: http://scikit- Thanks for contributing! --

n_clusters_per_class : int, optional (default=2)         The number of clusters per class.     weights : list of floats or None (default=None)    weights : array-like of shape (n_classes,) or (n_classes - 1,),\              (default=None)         The proportions of samples assigned to each class. If None, then         classes are balanced. Note that if ``len(weights) == n_classes - 1``,         then the last class weight is automatically inferred.


Question: datasets :: makeclassification() weights parameter should be a sequence (not just a list). If there is a pertinent reason that must be a list, while all other iterable parameters are arrays, then it should be mentioned in the docstring. Otherwise, the docstring should be amended as in , e.g. "weights : list of floats or None (default=None)" -"weights : sequence of floats or None (default=None)", along with amended lines 165 and 171 (see Corrections). Should not fail: as valid as a list: #wimlds [MRG] Added an example to the …or class <!-- Thanks for contributing a pull request! Please ensure you have taken a look at the contribution guidelines: --<!-- Contributes to . --I an example to the () <!-- Please be aware that we are a loose team of volunteers so patience is necessary; assistance handling other issues is very welcome. We value all user contributions, no matter how minor they are. If we are slow to review, either the pull request needs some benchmarking, tinkering, convincing, etc. or more likely the reviewers are simply busy. In either case, we ask for your understanding during the review process. For more information, see our FAQ on this topic: http://scikit- Thanks for contributing! --

" features")     # Use log2 to avoid overflow errors     if n_informative < np.log2(n_classes * n_clusters_per_class):        raise ValueError("n_classes * n_clusters_per_class must"                         " be smaller or equal 2 ** n_informative")    if weights and len(weights) not in [n_classes, n_classes - 1]:        raise ValueError("Weights specified but incompatible with number "                         "of classes.")        msg = "n_classes({}) * n_clusters_per_class({}) must be"        msg += " smaller or equal 2**n_informative({})={}"        raise ValueError(msg.format(n_classes, n_clusters_per_class,                                    n_informative, 2**n_informative))    if weights is not None:        if len(weights) not in [n_classes, n_classes - 1]:            raise ValueError("Weights specified but incompatible with number "                             "of classes.")        if len(weights) == n_classes - 1:            if isinstance(weights, list):                weights = weights + [1.0 - sum(weights)]            else:                weights = np.resize(weights, n_classes)                weights[-1] = 1.0 - sum(weights[:-1])    else:        weights = [1.0 / n_classes] * n_classes      n_useless = n_features - n_informative - n_redundant - n_repeated     n_clusters = n_classes * n_clusters_per_class     if weights and len(weights) == (n_classes - 1):        weights = weights + [1.0 - sum(weights)]    if weights is None:        weights = [1.0 / n_classes] * n_classes        weights[-1] = 1.0 - sum(weights[:-1])     # Distribute samples among clusters by weight     n_samples_per_cluster = [         int(n_samples * weights[k % n_classes] / n_clusters_per_class)


Question: IterativeImputer behaviour on missing nan's in fit data Why is this behaviour forced: Features with missing values during transform which did not have any missing values during fit will be imputed with the initial imputation method only. This means by default it will return the mean of that feature. I would prefer just fit one iteration of the chosen estimator and use that fitted estimator to impute missing values. Actual behaviour: Example - The second feature missing --mean imputation Example adjusted - Second feature has values --iterative imputation with estimator Maybe line 679 to 683 should be optional with a parameter like force-iterimpute.

"random"             A random order for each round. <ins>    skip_complete : boolean, optional (default=False)        If ``True`` then features with missing values during ``transform``        which did not have any missing values during ``fit`` will be imputed        with the initial imputation method only. Set to ``True`` if you have        many features with no missing values at both ``fit`` and ``transform``        time to save compute.</ins>     min_value : float, optional (default=None)         Minimum possible imputed value. Default of ``None`` will set minimum         to negative infinity.


Question: IterativeImputer behaviour on missing nan's in fit data Why is this behaviour forced: Features with missing values during transform which did not have any missing values during fit will be imputed with the initial imputation method only. This means by default it will return the mean of that feature. I would prefer just fit one iteration of the chosen estimator and use that fitted estimator to impute missing values. Actual behaviour: Example - The second feature missing --mean imputation Example adjusted - Second feature has values --iterative imputation with estimator Maybe line 679 to 683 should be optional with a parameter like force-iterimpute.

Indicator used to add binary indicators for missing values.         ``None`` if add_indicator is False. <ins>    random_state_ : RandomState instance        RandomState instance that is generated either from a seed, the random        number generator or by `np.random`.</ins>     See also     --------     SimpleImputer : Univariate imputation of missing values.


Question: IterativeImputer behaviour on missing nan's in fit data Why is this behaviour forced: Features with missing values during transform which did not have any missing values during fit will be imputed with the initial imputation method only. This means by default it will return the mean of that feature. I would prefer just fit one iteration of the chosen estimator and use that fitted estimator to impute missing values. Actual behaviour: Example - The second feature missing --mean imputation Example adjusted - Second feature has values --iterative imputation with estimator Maybe line 679 to 683 should be optional with a parameter like force-iterimpute.

Features which contain all missing values at ``fit`` are discarded upon     ``transform``. <del>    Features with missing values during ``transform`` which did not have any    missing values during ``fit`` will be imputed with the initial imputation    method only.</del>     References     ----------     .. [1] `Stef van Buuren, Karin Groothuis-Oudshoorn (2011). "mice:


Question: IterativeImputer behaviour on missing nan's in fit data Why is this behaviour forced: Features with missing values during transform which did not have any missing values during fit will be imputed with the initial imputation method only. This means by default it will return the mean of that feature. I would prefer just fit one iteration of the chosen estimator and use that fitted estimator to impute missing values. Actual behaviour: Example - The second feature missing --mean imputation Example adjusted - Second feature has values --iterative imputation with estimator Maybe line 679 to 683 should be optional with a parameter like force-iterimpute.

n_nearest_features=None,                  initial_strategy="mean",                  imputation_order='ascending',<ins>                 skip_complete=False,</ins>                  min_value=None,                  max_value=None,                  verbose=0,


Question: IterativeImputer behaviour on missing nan's in fit data Why is this behaviour forced: Features with missing values during transform which did not have any missing values during fit will be imputed with the initial imputation method only. This means by default it will return the mean of that feature. I would prefer just fit one iteration of the chosen estimator and use that fitted estimator to impute missing values. Actual behaviour: Example - The second feature missing --mean imputation Example adjusted - Second feature has values --iterative imputation with estimator Maybe line 679 to 683 should be optional with a parameter like force-iterimpute.

self.n_nearest_features = n_nearest_features         self.initial_strategy = initial_strategy         self.imputation_order = imputation_order<ins>        self.skip_complete = skip_complete</ins>         self.min_value = min_value         self.max_value = max_value         self.verbose = verbose


Question: IterativeImputer behaviour on missing nan's in fit data Why is this behaviour forced: Features with missing values during transform which did not have any missing values during fit will be imputed with the initial imputation method only. This means by default it will return the mean of that feature. I would prefer just fit one iteration of the chosen estimator and use that fitted estimator to impute missing values. Actual behaviour: Example - The second feature missing --mean imputation Example adjusted - Second feature has values --iterative imputation with estimator Maybe line 679 to 683 should be optional with a parameter like force-iterimpute.

The fitted estimator used to impute             ``X_filled[missing_row_mask, feat_idx]``.         """<del>        # if nothing is missing, just return the default        # (should not happen at fit time because feat_ids would be excluded)        missing_row_mask = mask_missing_values[:, feat_idx]        if not np.any(missing_row_mask):            return X_filled, estimator</del>         if estimator is None and fit_mode is False:             raise ValueError("If fit_mode is False, then an already-fitted "                              "estimator should be passed in.")


Question: IterativeImputer behaviour on missing nan's in fit data Why is this behaviour forced: Features with missing values during transform which did not have any missing values during fit will be imputed with the initial imputation method only. This means by default it will return the mean of that feature. I would prefer just fit one iteration of the chosen estimator and use that fitted estimator to impute missing values. Actual behaviour: Example - The second feature missing --mean imputation Example adjusted - Second feature has values --iterative imputation with estimator Maybe line 679 to 683 should be optional with a parameter like force-iterimpute.

if estimator is None:             estimator = clone(self._estimator) <ins>        missing_row_mask = mask_missing_values[:, feat_idx]</ins>         if fit_mode:             X_train = safe_indexing(X_filled[:, neighbor_feat_idx],                                     ~missing_row_mask)


Question: IterativeImputer behaviour on missing nan's in fit data Why is this behaviour forced: Features with missing values during transform which did not have any missing values during fit will be imputed with the initial imputation method only. This means by default it will return the mean of that feature. I would prefer just fit one iteration of the chosen estimator and use that fitted estimator to impute missing values. Actual behaviour: Example - The second feature missing --mean imputation Example adjusted - Second feature has values --iterative imputation with estimator Maybe line 679 to 683 should be optional with a parameter like force-iterimpute.

~missing_row_mask)             estimator.fit(X_train, y_train)         # get posterior samples        # if no missing values, don't predict        if np.sum(missing_row_mask) == 0:            return X_filled, estimator        # get posterior samples if there is at least one missing value         X_test = safe_indexing(X_filled[:, neighbor_feat_idx],                                missing_row_mask)         if self.sample_posterior:             mus, sigmas = estimator.predict(X_test, return_std=True)             imputed_values = np.zeros(mus.shape, dtype=X_filled.dtype)            # two types of problems: (1) non-positive sigmas, (2) mus outside            # legal range of min_value and max_value (results in inf sample)            # two types of problems: (1) non-positive sigmas            # (2) mus outside legal range of min_value and max_value            # (results in inf sample)             positive_sigmas = sigmas > 0             imputed_values[~positive_sigmas] = mus[~positive_sigmas]             mus_too_low = mus < self._min_value


Question: IterativeImputer behaviour on missing nan's in fit data Why is this behaviour forced: Features with missing values during transform which did not have any missing values during fit will be imputed with the initial imputation method only. This means by default it will return the mean of that feature. I would prefer just fit one iteration of the chosen estimator and use that fitted estimator to impute missing values. Actual behaviour: Example - The second feature missing --mean imputation Example adjusted - Second feature has values --iterative imputation with estimator Maybe line 679 to 683 should be optional with a parameter like force-iterimpute.

The order in which to impute the features.         """         frac_of_missing_values = mask_missing_values.mean(axis=0)        missing_values_idx = np.nonzero(frac_of_missing_values)[0]        if self.skip_complete:            missing_values_idx = np.flatnonzero(frac_of_missing_values)        else:            missing_values_idx = np.arange(np.shape(frac_of_missing_values)[0])         if self.imputation_order == 'roman':             ordered_idx = missing_values_idx         elif self.imputation_order == 'arabic':


Question: IterativeImputer behaviour on missing nan's in fit data Why is this behaviour forced: Features with missing values during transform which did not have any missing values during fit will be imputed with the initial imputation method only. This means by default it will return the mean of that feature. I would prefer just fit one iteration of the chosen estimator and use that fitted estimator to impute missing values. Actual behaviour: Example - The second feature missing --mean imputation Example adjusted - Second feature has values --iterative imputation with estimator Maybe line 679 to 683 should be optional with a parameter like force-iterimpute.

self.initial_imputer_ = None         X, Xt, mask_missing_values = self._initial_imputation(X)         if self.max_iter == 0 or np.all(mask_missing_values):             self.n_iter_ = 0             return Xt         # Edge case: a single feature. We return the initial ...        if Xt.shape[1] == 1:            self.n_iter_ = 0            return Xt         # order in which to impute         # note this is probably too slow for large feature data (d > 100000)         # and a better way would be good.


Question: HGBC with categoricalcrossentropy fails silently on binary classification gives: And works fine. should either generalize or raise an error on binary classification. Ping

return encoded_y      def _get_loss(self):<ins>        if (self.loss == 'categorical_crossentropy' and                self.n_trees_per_iteration_ == 1):            raise ValueError("'categorical_crossentropy' is not suitable for "                             "a binary classification problem. Please use "                             "'auto' or 'binary_crossentropy' instead.")</ins>         if self.loss == 'auto':             if self.n_trees_per_iteration_ == 1:                 return _LOSSES['binary_crossentropy']()


Question: Fitting TransformedTargetRegressor with sampleweight in Pipeline Can't fit a using . May be link to ? Example: ! Fitting with <!-- Thanks for contributing! --

" you are sure you want to proceed regardless"                               ", set 'check_inverse=False'", UserWarning)     def fit(self, X, y, sample_weight=None):    def fit(self, X, y, **fit_params):         """Fit the model according to the given training data.          Parameters


Question: Fitting TransformedTargetRegressor with sampleweight in Pipeline Can't fit a using . May be link to ? Example: ! Fitting with <!-- Thanks for contributing! --

y : array-like, shape (n_samples,)             Target values.         sample_weight : array-like, shape (n_samples,) optional            Array of weights that are assigned to individual samples.            If not provided, then each sample is given unit weight.        **fit_params : dict of string -> object            Parameters passed to the ``fit`` method of the underlying            regressor.          Returns         -------


Question: Fitting TransformedTargetRegressor with sampleweight in Pipeline Can't fit a using . May be link to ? Example: ! Fitting with <!-- Thanks for contributing! --

else:             self.regressor_ = clone(self.regressor)         if sample_weight is None:            self.regressor_.fit(X, y_trans)        else:            self.regressor_.fit(X, y_trans, sample_weight=sample_weight)        self.regressor_.fit(X, y_trans, **fit_params)          return self


Question: ZeroDivisionError in sparsefit for SVM with empty supportvectors When using sparse data, in the case where the supportvectors attribute is be empty, fitsparse gives a ZeroDivisionError No error is thrown and

n_SV = self.support_vectors_.shape[0]          dual_coef_indices = np.tile(np.arange(n_SV), n_class)        dual_coef_indptr = np.arange(0, dual_coef_indices.size + 1,                                     dual_coef_indices.size / n_class)        self.dual_coef_ = sp.csr_matrix(            (dual_coef_data, dual_coef_indices, dual_coef_indptr),            (n_class, n_SV))        if not n_SV:            self.dual_coef_ = sp.csr_matrix([])        else:            dual_coef_indptr = np.arange(0, dual_coef_indices.size + 1,                                         dual_coef_indices.size / n_class)            self.dual_coef_ = sp.csr_matrix(                (dual_coef_data, dual_coef_indices, dual_coef_indptr),                (n_class, n_SV))      def predict(self, X):         """Perform regression on samples in X.


Question: Documentation section 3.3.1.1 has incorrect description of brierscoreloss In the documentation, section 3.3.1.1. "Common cases: predefined values" includes the remark As far as I can tell, this is true for all of the listed metrics, except the . In the case of , a lower loss value is better. This is because measures the mean-square difference between a predicted probability and a categorical outcome; the Brier score is minimized at 0.0 because all summands are either or when the model is making perfect predictions. On the other hand, the Brier score is maximized at 1.0 when all predictions are opposite the correct label, as all summands are either or . Therefore, the definition of the is not consistent with the quotation from section 3.3.1.1. I suggest making 2 changes to relieve this confusion. a function which simply negates the value of ; this is a direct analogy to what is done in the case of . A better model has a lower value of log-loss (categorical cross-entropy loss), therefore a larger value of the negative log-loss implies a better model. Naturally, the same is true for Brier score, where it is also the case that a better model is assigned a lower loss. reference to from section 3.3.1.1. Brier score is useful in lots of ways; however, because it does not have the property that a larger value implies a better model, it seems confusing to mention it in the context of section 3.3.1.1. References to can be replaced with , which has the property that better models have large values, just like accuracy, ROC AUC and the rest of the listed metrics.

raise ValueError("y_prob contains values less than 0.")      # if pos_label=None, when y_true is in {-1, 1} or {0, 1},    # pos_labe is set to 1 (consistent with precision_recall_curve/roc_curve),    # pos_label is set to 1 (consistent with precision_recall_curve/roc_curve),     # otherwise pos_label is set to the greater label     # (different from precision_recall_curve/roc_curve,     # the purpose is to keep backward compatibility).diff --git a/sklearn/metrics/scorer.py b/sklearn/metrics/scorer.py-- a/sklearn/metrics/scorer.py++ b/sklearn/metrics/scorer.py


Question: Documentation section 3.3.1.1 has incorrect description of brierscoreloss In the documentation, section 3.3.1.1. "Common cases: predefined values" includes the remark As far as I can tell, this is true for all of the listed metrics, except the . In the case of , a lower loss value is better. This is because measures the mean-square difference between a predicted probability and a categorical outcome; the Brier score is minimized at 0.0 because all summands are either or when the model is making perfect predictions. On the other hand, the Brier score is maximized at 1.0 when all predictions are opposite the correct label, as all summands are either or . Therefore, the definition of the is not consistent with the quotation from section 3.3.1.1. I suggest making 2 changes to relieve this confusion. a function which simply negates the value of ; this is a direct analogy to what is done in the case of . A better model has a lower value of log-loss (categorical cross-entropy loss), therefore a larger value of the negative log-loss implies a better model. Naturally, the same is true for Brier score, where it is also the case that a better model is assigned a lower loss. reference to from section 3.3.1.1. Brier score is useful in lots of ways; however, because it does not have the property that a larger value implies a better model, it seems confusing to mention it in the context of section 3.3.1.1. References to can be replaced with , which has the property that better models have large values, just like accuracy, ROC AUC and the rest of the listed metrics.

from collections.abc import Iterable from functools import partial from collections import Counter<ins>import warnings</ins>  import numpy as np


Question: Documentation section 3.3.1.1 has incorrect description of brierscoreloss In the documentation, section 3.3.1.1. "Common cases: predefined values" includes the remark As far as I can tell, this is true for all of the listed metrics, except the . In the case of , a lower loss value is better. This is because measures the mean-square difference between a predicted probability and a categorical outcome; the Brier score is minimized at 0.0 because all summands are either or when the model is making perfect predictions. On the other hand, the Brier score is maximized at 1.0 when all predictions are opposite the correct label, as all summands are either or . Therefore, the definition of the is not consistent with the quotation from section 3.3.1.1. I suggest making 2 changes to relieve this confusion. a function which simply negates the value of ; this is a direct analogy to what is done in the case of . A better model has a lower value of log-loss (categorical cross-entropy loss), therefore a larger value of the negative log-loss implies a better model. Naturally, the same is true for Brier score, where it is also the case that a better model is assigned a lower loss. reference to from section 3.3.1.1. Brier score is useful in lots of ways; however, because it does not have the property that a larger value implies a better model, it seems confusing to mention it in the context of section 3.3.1.1. References to can be replaced with , which has the property that better models have large values, just like accuracy, ROC AUC and the rest of the listed metrics.

self._kwargs = kwargs         self._score_func = score_func         self._sign = sign<ins>        # XXX After removing the deprecated scorers (v0.24) remove the        # XXX deprecation_msg property again and remove __call__'s body again        self._deprecation_msg = None</ins>      def __repr__(self):         kwargs_string = "".join([", %s=%s" % (str(k), str(v))


Question: Documentation section 3.3.1.1 has incorrect description of brierscoreloss In the documentation, section 3.3.1.1. "Common cases: predefined values" includes the remark As far as I can tell, this is true for all of the listed metrics, except the . In the case of , a lower loss value is better. This is because measures the mean-square difference between a predicted probability and a categorical outcome; the Brier score is minimized at 0.0 because all summands are either or when the model is making perfect predictions. On the other hand, the Brier score is maximized at 1.0 when all predictions are opposite the correct label, as all summands are either or . Therefore, the definition of the is not consistent with the quotation from section 3.3.1.1. I suggest making 2 changes to relieve this confusion. a function which simply negates the value of ; this is a direct analogy to what is done in the case of . A better model has a lower value of log-loss (categorical cross-entropy loss), therefore a larger value of the negative log-loss implies a better model. Naturally, the same is true for Brier score, where it is also the case that a better model is assigned a lower loss. reference to from section 3.3.1.1. Brier score is useful in lots of ways; however, because it does not have the property that a larger value implies a better model, it seems confusing to mention it in the context of section 3.3.1.1. References to can be replaced with , which has the property that better models have large values, just like accuracy, ROC AUC and the rest of the listed metrics.

score : float             Score function applied to prediction of estimator on X.         """<ins>        if self._deprecation_msg is not None:            warnings.warn(self._deprecation_msg,                          category=DeprecationWarning,                          stacklevel=2)</ins>         return self._score(partial(_cached_call, None), estimator, X, y_true,                            sample_weight=sample_weight)


Question: Documentation section 3.3.1.1 has incorrect description of brierscoreloss In the documentation, section 3.3.1.1. "Common cases: predefined values" includes the remark As far as I can tell, this is true for all of the listed metrics, except the . In the case of , a lower loss value is better. This is because measures the mean-square difference between a predicted probability and a categorical outcome; the Brier score is minimized at 0.0 because all summands are either or when the model is making perfect predictions. On the other hand, the Brier score is maximized at 1.0 when all predictions are opposite the correct label, as all summands are either or . Therefore, the definition of the is not consistent with the quotation from section 3.3.1.1. I suggest making 2 changes to relieve this confusion. a function which simply negates the value of ; this is a direct analogy to what is done in the case of . A better model has a lower value of log-loss (categorical cross-entropy loss), therefore a larger value of the negative log-loss implies a better model. Naturally, the same is true for Brier score, where it is also the case that a better model is assigned a lower loss. reference to from section 3.3.1.1. Brier score is useful in lots of ways; however, because it does not have the property that a larger value implies a better model, it seems confusing to mention it in the context of section 3.3.1.1. References to can be replaced with , which has the property that better models have large values, just like accuracy, ROC AUC and the rest of the listed metrics.

score : float             Score function applied to prediction of estimator on X.         """<ins></ins>         y_pred = method_caller(estimator, "predict", X)         if sample_weight is not None:             return self._sign * self._score_func(y_true, y_pred,


Question: Documentation section 3.3.1.1 has incorrect description of brierscoreloss In the documentation, section 3.3.1.1. "Common cases: predefined values" includes the remark As far as I can tell, this is true for all of the listed metrics, except the . In the case of , a lower loss value is better. This is because measures the mean-square difference between a predicted probability and a categorical outcome; the Brier score is minimized at 0.0 because all summands are either or when the model is making perfect predictions. On the other hand, the Brier score is maximized at 1.0 when all predictions are opposite the correct label, as all summands are either or . Therefore, the definition of the is not consistent with the quotation from section 3.3.1.1. I suggest making 2 changes to relieve this confusion. a function which simply negates the value of ; this is a direct analogy to what is done in the case of . A better model has a lower value of log-loss (categorical cross-entropy loss), therefore a larger value of the negative log-loss implies a better model. Naturally, the same is true for Brier score, where it is also the case that a better model is assigned a lower loss. reference to from section 3.3.1.1. Brier score is useful in lots of ways; however, because it does not have the property that a larger value implies a better model, it seems confusing to mention it in the context of section 3.3.1.1. References to can be replaced with , which has the property that better models have large values, just like accuracy, ROC AUC and the rest of the listed metrics.

score : float             Score function applied to prediction of estimator on X.         """<ins></ins>         y_type = type_of_target(y)         y_pred = method_caller(clf, "predict_proba", X)         if y_type == "binary":


Question: Documentation section 3.3.1.1 has incorrect description of brierscoreloss In the documentation, section 3.3.1.1. "Common cases: predefined values" includes the remark As far as I can tell, this is true for all of the listed metrics, except the . In the case of , a lower loss value is better. This is because measures the mean-square difference between a predicted probability and a categorical outcome; the Brier score is minimized at 0.0 because all summands are either or when the model is making perfect predictions. On the other hand, the Brier score is maximized at 1.0 when all predictions are opposite the correct label, as all summands are either or . Therefore, the definition of the is not consistent with the quotation from section 3.3.1.1. I suggest making 2 changes to relieve this confusion. a function which simply negates the value of ; this is a direct analogy to what is done in the case of . A better model has a lower value of log-loss (categorical cross-entropy loss), therefore a larger value of the negative log-loss implies a better model. Naturally, the same is true for Brier score, where it is also the case that a better model is assigned a lower loss. reference to from section 3.3.1.1. Brier score is useful in lots of ways; however, because it does not have the property that a larger value implies a better model, it seems confusing to mention it in the context of section 3.3.1.1. References to can be replaced with , which has the property that better models have large values, just like accuracy, ROC AUC and the rest of the listed metrics.

score : float             Score function applied to prediction of estimator on X.         """<ins></ins>         y_type = type_of_target(y)         if y_type not in ("binary", "multilabel-indicator"):             raise ValueError("{0} format is not supported".format(y_type))


Question: Documentation section 3.3.1.1 has incorrect description of brierscoreloss In the documentation, section 3.3.1.1. "Common cases: predefined values" includes the remark As far as I can tell, this is true for all of the listed metrics, except the . In the case of , a lower loss value is better. This is because measures the mean-square difference between a predicted probability and a categorical outcome; the Brier score is minimized at 0.0 because all summands are either or when the model is making perfect predictions. On the other hand, the Brier score is maximized at 1.0 when all predictions are opposite the correct label, as all summands are either or . Therefore, the definition of the is not consistent with the quotation from section 3.3.1.1. I suggest making 2 changes to relieve this confusion. a function which simply negates the value of ; this is a direct analogy to what is done in the case of . A better model has a lower value of log-loss (categorical cross-entropy loss), therefore a larger value of the negative log-loss implies a better model. Naturally, the same is true for Brier score, where it is also the case that a better model is assigned a lower loss. reference to from section 3.3.1.1. Brier score is useful in lots of ways; however, because it does not have the property that a larger value implies a better model, it seems confusing to mention it in the context of section 3.3.1.1. References to can be replaced with , which has the property that better models have large values, just like accuracy, ROC AUC and the rest of the listed metrics.

"""     if isinstance(scoring, str):         try:            scorer = SCORERS[scoring]            if scoring == 'brier_score_loss':                # deprecated                scorer = brier_score_loss_scorer            else:                scorer = SCORERS[scoring]         except KeyError:             raise ValueError('%r is not a valid scoring value. '                              'Use sorted(sklearn.metrics.SCORERS.keys()) '                             'to get valid options.' % (scoring))                             'to get valid options.' % scoring)     else:         scorer = scoring     return scorer


Question: Documentation section 3.3.1.1 has incorrect description of brierscoreloss In the documentation, section 3.3.1.1. "Common cases: predefined values" includes the remark As far as I can tell, this is true for all of the listed metrics, except the . In the case of , a lower loss value is better. This is because measures the mean-square difference between a predicted probability and a categorical outcome; the Brier score is minimized at 0.0 because all summands are either or when the model is making perfect predictions. On the other hand, the Brier score is maximized at 1.0 when all predictions are opposite the correct label, as all summands are either or . Therefore, the definition of the is not consistent with the quotation from section 3.3.1.1. I suggest making 2 changes to relieve this confusion. a function which simply negates the value of ; this is a direct analogy to what is done in the case of . A better model has a lower value of log-loss (categorical cross-entropy loss), therefore a larger value of the negative log-loss implies a better model. Naturally, the same is true for Brier score, where it is also the case that a better model is assigned a lower loss. reference to from section 3.3.1.1. Brier score is useful in lots of ways; however, because it does not have the property that a larger value implies a better model, it seems confusing to mention it in the context of section 3.3.1.1. References to can be replaced with , which has the property that better models have large values, just like accuracy, ROC AUC and the rest of the listed metrics.

# Score function for probabilistic classification neg_log_loss_scorer = make_scorer(log_loss, greater_is_better=False,                                   needs_proba=True)neg_brier_score_scorer = make_scorer(brier_score_loss,                                     greater_is_better=False,                                     needs_proba=True) brier_score_loss_scorer = make_scorer(brier_score_loss,                                       greater_is_better=False,                                       needs_proba=True)deprecation_msg = ('Scoring method brier_score_loss was renamed to '                   'neg_brier_score in version 0.22 and will '                   'be removed in 0.24.')brier_score_loss_scorer._deprecation_msg = deprecation_msg   # Clustering scores


Question: Documentation section 3.3.1.1 has incorrect description of brierscoreloss In the documentation, section 3.3.1.1. "Common cases: predefined values" includes the remark As far as I can tell, this is true for all of the listed metrics, except the . In the case of , a lower loss value is better. This is because measures the mean-square difference between a predicted probability and a categorical outcome; the Brier score is minimized at 0.0 because all summands are either or when the model is making perfect predictions. On the other hand, the Brier score is maximized at 1.0 when all predictions are opposite the correct label, as all summands are either or . Therefore, the definition of the is not consistent with the quotation from section 3.3.1.1. I suggest making 2 changes to relieve this confusion. a function which simply negates the value of ; this is a direct analogy to what is done in the case of . A better model has a lower value of log-loss (categorical cross-entropy loss), therefore a larger value of the negative log-loss implies a better model. Naturally, the same is true for Brier score, where it is also the case that a better model is assigned a lower loss. reference to from section 3.3.1.1. Brier score is useful in lots of ways; however, because it does not have the property that a larger value implies a better model, it seems confusing to mention it in the context of section 3.3.1.1. References to can be replaced with , which has the property that better models have large values, just like accuracy, ROC AUC and the rest of the listed metrics.

balanced_accuracy=balanced_accuracy_scorer,                average_precision=average_precision_scorer,                neg_log_loss=neg_log_loss_scorer,               brier_score_loss=brier_score_loss_scorer,               neg_brier_score=neg_brier_score_scorer,                # Cluster metrics that use supervised evaluation                adjusted_rand_score=adjusted_rand_scorer,                homogeneity_score=homogeneity_scorer,


Question: Error could be improved with DummyClassifier constant strategy when constant value not in training data Error: We could add in the error message what constant value was provided (in this case ) and what the possible values are. This could be something like this (improvement more than welcome): Context: this was seen during the EuroScipy tutorial. The adult census dataset classes has a space in it at the beginning and the provided value did not have the space. Putting what the provided value was and what were the possible values would have helped the user fixing the problem.

self.n_classes_,          self.class_prior_) = class_distribution(y, sample_weight)         if (self.strategy == "constant" and                any(constant[k] not in self.classes_[k]                    for k in range(self.n_outputs_))):            # Checking in case of constant strategy if the constant            # provided by the user is in y.            raise ValueError("The constant target value must be "                             "present in training data")        if self.strategy == "constant":            for k in range(self.n_outputs_):                if not any(constant[k][0] == c for c in self.classes_[k]):                    # Checking in case of constant strategy if the constant                    # provided by the user is in y.                    err_msg = ("The constant target value must be present in "                               "the training data. You provided constant={}. "                               "Possible values are: {}."                               .format(self.constant, list(self.classes_[k])))                    raise ValueError(err_msg)          if self.n_outputs_ == 1 and not self.output_2d_:             self.n_classes_ = self.n_classes_[0]


Question: RepeatedKFold and RepeatedStratifiedKFold do not show correct repr string and do not show correct \repr\ string.

**self.cvargs)         return cv.get_n_splits(X, y, groups) * self.n_repeats <ins>    def __repr__(self):        return _build_repr(self)</ins>  class RepeatedKFold(_RepeatedSplits):     """Repeated K-Fold cross validator.


Question: RepeatedKFold and RepeatedStratifiedKFold do not show correct repr string and do not show correct \repr\ string.

try:             with warnings.catch_warnings(record=True) as w:                 value = getattr(self, key, None)<ins>                if value is None and hasattr(self, 'cvargs'):                    value = self.cvargs.get(key, None)</ins>             if len(w) and w[0].category == DeprecationWarning:                 # if the parameter is deprecated, don't show it                 continue


Question: data leak in GBDT due to warm start (This is about the non-histogram-based version of GBDTs) X is split into train and validation data with . As noted, in a warm starting context, this will produce a leak if If is a instance: some samples that were used for training in a previous might be used for validation now.

X, y = check_X_y(X, y, dtype=[X_DTYPE], force_all_finite=False)         y = self._encode_y(y)         # The rng state must be preserved if warm_start is True        if (self.warm_start and hasattr(self, '_rng')):            rng = self._rng        else:            rng = check_random_state(self.random_state)            self._rng = rng        rng = check_random_state(self.random_state)        # When warm starting, we want to re-use the same seed that was used        # the first time fit was called (e.g. for subsampling or for the        # train/val split).        if not (self.warm_start and self._is_fitted()):            self._random_seed = rng.randint(np.iinfo(np.uint32).max,                                            dtype='u8')          self._validate_parameters()         self.n_features_ = X.shape[1]  # used for validation in predict()


Question: data leak in GBDT due to warm start (This is about the non-histogram-based version of GBDTs) X is split into train and validation data with . As noted, in a warm starting context, this will produce a leak if If is a instance: some samples that were used for training in a previous might be used for validation now.

# Save the state of the RNG for the training and validation split.             # This is needed in order to have the same split when using             # warm starting.            if not (self._is_fitted() and self.warm_start):                self._train_val_split_seed = rng.randint(1024)              X_train, X_val, y_train, y_val = train_test_split(                 X, y, test_size=self.validation_fraction, stratify=stratify,                random_state=self._train_val_split_seed)                random_state=self._random_seed)         else:             X_train, y_train = X, y             X_val, y_val = None, None


Question: data leak in GBDT due to warm start (This is about the non-histogram-based version of GBDTs) X is split into train and validation data with . As noted, in a warm starting context, this will produce a leak if If is a instance: some samples that were used for training in a previous might be used for validation now.

# actual total number of bins. Everywhere in the code, the         # convention is that n_bins == max_bins + 1         n_bins = self.max_bins + 1  # + 1 for missing values        self.bin_mapper_ = _BinMapper(n_bins=n_bins, random_state=rng)        X_binned_train = self._bin_data(X_train, rng, is_training_data=True)        self.bin_mapper_ = _BinMapper(n_bins=n_bins,                                      random_state=self._random_seed)        X_binned_train = self._bin_data(X_train, is_training_data=True)         if X_val is not None:            X_binned_val = self._bin_data(X_val, rng, is_training_data=False)            X_binned_val = self._bin_data(X_val, is_training_data=False)         else:             X_binned_val = None


Question: data leak in GBDT due to warm start (This is about the non-histogram-based version of GBDTs) X is split into train and validation data with . As noted, in a warm starting context, this will produce a leak if If is a instance: some samples that were used for training in a previous might be used for validation now.

# the predictions of all the trees. So we use a subset of                     # the training set to compute train scores.                     # Save the seed for the small trainset generator                    self._small_trainset_seed = rng.randint(1024)                     # Compute the subsample set                     (X_binned_small_train,                      y_small_train) = self._get_small_trainset(                        X_binned_train, y_train, self._small_trainset_seed)                        X_binned_train, y_train, self._random_seed)                      self._check_early_stopping_scorer(                         X_binned_small_train, y_small_train,


Question: data leak in GBDT due to warm start (This is about the non-histogram-based version of GBDTs) X is split into train and validation data with . As noted, in a warm starting context, this will produce a leak if If is a instance: some samples that were used for training in a previous might be used for validation now.

if self.do_early_stopping_ and self.scoring != 'loss':                 # Compute the subsample set                 X_binned_small_train, y_small_train = self._get_small_trainset(                    X_binned_train, y_train, self._small_trainset_seed)                    X_binned_train, y_train, self._random_seed)              # Initialize the gradients and hessians             gradients, hessians = self.loss_.init_gradients_and_hessians(


Question: data leak in GBDT due to warm start (This is about the non-histogram-based version of GBDTs) X is split into train and validation data with . As noted, in a warm starting context, this will produce a leak if If is a instance: some samples that were used for training in a previous might be used for validation now.

def _clear_state(self):         """Clear the state of the gradient boosting model."""        for var in ('train_score_', 'validation_score_', '_rng'):        for var in ('train_score_', 'validation_score_'):             if hasattr(self, var):                 delattr(self, var)


Question: data leak in GBDT due to warm start (This is about the non-histogram-based version of GBDTs) X is split into train and validation data with . As noted, in a warm starting context, this will produce a leak if If is a instance: some samples that were used for training in a previous might be used for validation now.

for score in recent_scores]         return not any(recent_improvements)     def _bin_data(self, X, rng, is_training_data):    def _bin_data(self, X, is_training_data):         """Bin data X.          If is_training_data, then set the bin_mapper_ attribute.


Question: Deprecate classes attribute in DecisionTreeRegressor This partially relates to issue Currently, if you fit a decision tree regressor, and call the attribute , it will return none. This attribute does not appear on the doc string and shouldn't. This was surfaced from an issue related to mismatch attributes ( ) Reviewed the and worked with on different options including using a decorator on a property but it triggered the deprecation message when calling fit which was bad. In this PR, the was changed to in the parent. And a test was to the

import numpy as np  from ..utils.validation import check_is_fitted<ins>from ..base import is_classifier</ins>  from . import _criterion from . import _tree


Question: Deprecate classes attribute in DecisionTreeRegressor This partially relates to issue Currently, if you fit a decision tree regressor, and call the attribute , it will return none. This attribute does not appear on the doc string and shouldn't. This was surfaced from an issue related to mismatch attributes ( ) Reviewed the and worked with on different options including using a decorator on a property but it triggered the deprecation message when calling fit which was bad. In this PR, the was changed to in the parent. And a test was to the

"""     check_is_fitted(decision_tree)     tree_ = decision_tree.tree_    class_names = decision_tree.classes_    if is_classifier(decision_tree):        class_names = decision_tree.classes_     right_child_fmt = "{} {} <= {}\n"     left_child_fmt = "{} {} >  {}\n"     truncation_fmt = "{} {}\n"diff --git a/sklearn/tree/tree.py b/sklearn/tree/tree.py-- a/sklearn/tree/tree.py++ b/sklearn/tree/tree.py


Question: Deprecate classes attribute in DecisionTreeRegressor This partially relates to issue Currently, if you fit a decision tree regressor, and call the attribute , it will return none. This attribute does not appear on the doc string and shouldn't. This was surfaced from an issue related to mismatch attributes ( ) Reviewed the and worked with on different options including using a decorator on a property but it triggered the deprecation message when calling fit which was bad. In this PR, the was changed to in the parent. And a test was to the

expanded_class_weight = compute_sample_weight(                     self.class_weight, y_original)         else:            self.classes_ = [None] * self.n_outputs_            self.n_classes_ = [1] * self.n_outputs_        self.n_classes_ = np.array(self.n_classes_, dtype=np.intp)            self.n_classes_ = np.array(self.n_classes_, dtype=np.intp)          if getattr(y, "dtype", None) != DOUBLE or not y.flags.contiguous:             y = np.ascontiguousarray(y, dtype=DOUBLE)


Question: Deprecate classes attribute in DecisionTreeRegressor This partially relates to issue Currently, if you fit a decision tree regressor, and call the attribute , it will return none. This attribute does not appear on the doc string and shouldn't. This was surfaced from an issue related to mismatch attributes ( ) Reviewed the and worked with on different options including using a decorator on a property but it triggered the deprecation message when calling fit which was bad. In this PR, the was changed to in the parent. And a test was to the

min_weight_leaf,                                                 random_state)         self.tree_ = Tree(self.n_features_, self.n_classes_, self.n_outputs_)        if is_classifier(self):            self.tree_ = Tree(self.n_features_,                              self.n_classes_, self.n_outputs_)        else:            self.tree_ = Tree(self.n_features_,                              # TODO: tree should't need this in this case                              np.array([1] * self.n_outputs_, dtype=np.intp),                              self.n_outputs_)          # Use BestFirst if max_leaf_nodes given; use DepthFirst otherwise         if max_leaf_nodes < 0:


Question: Deprecate classes attribute in DecisionTreeRegressor This partially relates to issue Currently, if you fit a decision tree regressor, and call the attribute , it will return none. This attribute does not appear on the doc string and shouldn't. This was surfaced from an issue related to mismatch attributes ( ) Reviewed the and worked with on different options including using a decorator on a property but it triggered the deprecation message when calling fit which was bad. In this PR, the was changed to in the parent. And a test was to the

builder.build(self.tree_, X, y, sample_weight, X_idx_sorted)         if self.n_outputs_ == 1:        if self.n_outputs_ == 1 and is_classifier(self):             self.n_classes_ = self.n_classes_[0]             self.classes_ = self.classes_[0]


Question: Deprecate classes attribute in DecisionTreeRegressor This partially relates to issue Currently, if you fit a decision tree regressor, and call the attribute , it will return none. This attribute does not appear on the doc string and shouldn't. This was surfaced from an issue related to mismatch attributes ( ) Reviewed the and worked with on different options including using a decorator on a property but it triggered the deprecation message when calling fit which was bad. In this PR, the was changed to in the parent. And a test was to the

if self.ccp_alpha == 0.0:             return         # build pruned treee        n_classes = np.atleast_1d(self.n_classes_)        pruned_tree = Tree(self.n_features_, n_classes, self.n_outputs_)        # build pruned tree        if is_classifier(self):            n_classes = np.atleast_1d(self.n_classes_)            pruned_tree = Tree(self.n_features_, n_classes, self.n_outputs_)        else:            pruned_tree = Tree(self.n_features_,                               # TODO: the tree shouldn't need this param                               np.array([1] * self.n_outputs_, dtype=np.intp),                               self.n_outputs_)         _build_pruned_tree_ccp(pruned_tree, self.tree_, self.ccp_alpha)          self.tree_ = pruned_tree


Question: Deprecate classes attribute in DecisionTreeRegressor This partially relates to issue Currently, if you fit a decision tree regressor, and call the attribute , it will return none. This attribute does not appear on the doc string and shouldn't. This was surfaced from an issue related to mismatch attributes ( ) Reviewed the and worked with on different options including using a decorator on a property but it triggered the deprecation message when calling fit which was bad. In this PR, the was changed to in the parent. And a test was to the

X_idx_sorted=X_idx_sorted)         return self <ins>    @property    def classes_(self):        # TODO: Remove method in 0.24        msg = ("the classes_ attribute is to be deprecated from version "               "0.22 and will be removed in 0.24.")        warnings.warn(msg, DeprecationWarning)        return np.array([None] * self.n_outputs_)    @property    def n_classes_(self):        # TODO: Remove method in 0.24        msg = ("the n_classes_ attribute is to be deprecated from version "               "0.22 and will be removed in 0.24.")        warnings.warn(msg, DeprecationWarning)        return np.array([1] * self.n_outputs_, dtype=np.intp)</ins>  class ExtraTreeClassifier(DecisionTreeClassifier):     """An extremely randomized tree classifier.


Question: MultiTaskLassoCV with fitintercept=True returns wrong results There is something wrong with and binary features. It always returns the same mse for all the alphas and hence chooses a huge regularization zeroing out all coefficients. The same holds for too. However, this doesn't happen with . Moreover it doesn't happen if I set , or if I generate random normal features. I am working on anaconda, windows system, with python 3.7.1 and with scikit-learn v0.21.3, numpy v1.16.2. Consider the following code: It returns On the other hand, if I generate normal features X, then things are good: which returns: Also weirdly if I set , then things are good even with binary features: which returns

# Let us not impose fortran ordering so far: it is             # not useful for the cross-validation loop and will be done             # by the model fitting itself            X = check_array(X, 'csc', copy=False)            X = check_array(X, 'csc', dtype=[np.float64, np.float32],                            copy=False)             if sparse.isspmatrix(X):                 if (hasattr(reference_to_old_X, "data") and                    not np.may_share_memory(reference_to_old_X.data, X.data)):


Question: MaxAbsScaler Upcasts Pandas to float64 <!-- If your issue is a usage question, submit it here instead: StackOverflow with the scikit-learn tag: Mailing List: For more information, see User Questions: http://scikit- --<!-- Instructions For Filing a Bug: --I am working with the Column transformer, and for memory issues, am trying to produce a float32 sparse matrix. Unfortunately, regardless of pandas input type, the output is always float64. I've identified one of the Pipeline scalers, MaxAbsScaler, as being the culprit. Other preprocessing functions, such as OneHotEncoder, have an optional argument. This argument does not exist in MaxAbsScaler (among others). It appears that the upcasting happens when is executed. Is it possible to specify a dtype? Or is there a commonly accepted practice to do so from the Column Transformer? Thank you! Example: Darwin-18.7.0-x8664-i386-64bit Python 3.6.7 (default, Jul 2 2019, 02:07:37) [GCC 4.2.1 Compatible Clang 4.0.1 (tags/RELEASE_401/final)] NumPy 1.17.1 SciPy 1.3.1 Scikit-Learn 0.20.3 Pandas 0.25.1

dtypes_orig = None     if hasattr(array, "dtypes") and hasattr(array.dtypes, '__array__'):         dtypes_orig = np.array(array.dtypes)<ins>        if all(isinstance(dtype, np.dtype) for dtype in dtypes_orig):            dtype_orig = np.result_type(*array.dtypes)</ins>      if dtype_numeric:         if dtype_orig is not None and dtype_orig.kind == "O":


Question: GridSearchCV saves all fitted estimator in cvresults['params'] when params are estimators I use GridSearchCV to optimize the hyperparameters of a pipeline. I set the param grid by inputing transformers or estimators at different steps of the pipeline, following the Pipeline documentation: I couldn't figure why dumping cvresults would take so much memory on disk. It happens that cvresults['params'] and all cvresults['param*'] objects contains fitted estimators, as much as there are points on my grid. This bug should happen only when njobs = 1 (which is my usecase). I don't think this is intended (else the arguments and attributes refit and best\estimator wouldn't be used). My guess is that during the grid search, those estimator's aren't cloned before use (which could be a problem if using the same grid search several times, because estimators passed in the next grid would be fitted...).

self.best_params_ = results["params"][self.best_index_]          if self.refit:            self.best_estimator_ = clone(base_estimator).set_params(                **self.best_params_)            # we clone again after setting params in case some            # of the params are estimators as well.            self.best_estimator_ = clone(clone(base_estimator).set_params(                **self.best_params_))             refit_start_time = time.time()             if y is not None:                 self.best_estimator_.fit(X, y, **fit_params)diff --git a/sklearn/model_selection/_validation.py b/sklearn/model_selection/_validation.py-- a/sklearn/model_selection/_validation.py++ b/sklearn/model_selection/_validation.py


Question: GridSearchCV saves all fitted estimator in cvresults['params'] when params are estimators I use GridSearchCV to optimize the hyperparameters of a pipeline. I set the param grid by inputing transformers or estimators at different steps of the pipeline, following the Pipeline documentation: I couldn't figure why dumping cvresults would take so much memory on disk. It happens that cvresults['params'] and all cvresults['param*'] objects contains fitted estimators, as much as there are points on my grid. This bug should happen only when njobs = 1 (which is my usecase). I don't think this is intended (else the arguments and attributes refit and best\estimator wouldn't be used). My guess is that during the grid search, those estimator's aren't cloned before use (which could be a problem if using the same grid search several times, because estimators passed in the next grid would be fitted...).

train_scores = {}     if parameters is not None:        estimator.set_params(**parameters)        # clone after setting parameters in case any parameters        # are estimators (like pipeline steps)        # because pipeline doesn't clone steps in fit        cloned_parameters = {}        for k, v in parameters.items():            cloned_parameters[k] = clone(v, safe=False)        estimator = estimator.set_params(**cloned_parameters)      start_time = time.time()


Question: stripaccentsunicode fails to strip accents from strings that are already in NFKD form <!-- If your issue is a usage question, submit it here instead: StackOverflow with the scikit-learn tag: Mailing List: For more information, see User Questions: http://scikit- --<!-- Instructions For Filing a Bug: --<!-- Example: Joblib Error thrown when calling fit on LatentDirichletAllocation with evaluateevery 0--The feature of and related does not work as expected when it processes strings that contain accents, if those strings are already in NFKD form. and should both be normalized to the same string, . is not changed, because does nothing if the string is already in NFKD form.

Remove accentuated char for any unicode symbol that has a direct         ASCII equivalent.     """    normalized = unicodedata.normalize('NFKD', s)    if normalized == s:    try:        # If `s` is ASCII-compatible, then it does not contain any accented        # characters and we can avoid an expensive list comprehension        s.encode("ASCII", errors="strict")         return s    else:    except UnicodeEncodeError:        normalized = unicodedata.normalize('NFKD', s)         return ''.join([c for c in normalized if not unicodedata.combining(c)])


Question: Inconsistent fit + transform and fittransform for FeatureUnion Is there a reason why the method signature accepts but neither nor do? It seems to go against the pattern that is the same as calling ? I see there's been discussion on supporting but it's not clear if this is resolved. My case is I'm trying to migrage code I wrote a while back where I used a Pipeline and each of my transformers adds columns to a dataframe, to a FeatureUnion where each transform only returns the new columns. One of my transforms takes a third data set in addition to X and y which is used as the transform. I guess as a workaround I'll make it a param of the transform rather than a fitarg.

trans.get_feature_names()])         return feature_names     def fit(self, X, y=None):    def fit(self, X, y=None, **fit_params):         """Fit all transformers using X.          Parameters


Question: Inconsistent fit + transform and fittransform for FeatureUnion Is there a reason why the method signature accepts but neither nor do? It seems to go against the pattern that is the same as calling ? I see there's been discussion on supporting but it's not clear if this is resolved. My case is I'm trying to migrage code I wrote a while back where I used a Pipeline and each of my transformers adds columns to a dataframe, to a FeatureUnion where each transform only returns the new columns. One of my transforms takes a third data set in addition to X and y which is used as the transform. I guess as a workaround I'll make it a param of the transform rather than a fitarg.

self : FeatureUnion             This estimator         """        transformers = self._parallel_func(X, y, {}, _fit_one)        transformers = self._parallel_func(X, y, fit_params, _fit_one)         if not transformers:             # All transformers are None             return self


Question: meanshift and MeanShift don't have the same API I'm trying to make call (related to ) but has a parameter and uses the default, so I cannot preserve backward compatibility without adding to . Should I just do that?

# If converged or at max_iter, adds the cluster         if (np.linalg.norm(my_mean - my_old_mean) < stop_thresh or                 completed_iterations == max_iter):            return tuple(my_mean), len(points_within)            break         completed_iterations += 1    return tuple(my_mean), len(points_within), completed_iterations   def mean_shift(X, bandwidth=None, seeds=None, bin_seeding=False,