scikit-learn · jnothman · May 9, 2019 · May 6, 2019 · May 1, 2019 · May 1, 2019
diff --git a/azure-pipelines.yml b/azure-pipelines.yml
@@ -22,6 +22,7 @@ jobs:
         SCIPY_VERSION: '0.17.0'
         CYTHON_VERSION: '*'
         PILLOW_VERSION: '4.0.0'
+        MATPLOTLIB_VERSION: '1.5.1'
         # later version of joblib are not packaged in conda for Python 3.5
         JOBLIB_VERSION: '0.12.3'
         COVERAGE: 'true'

diff --git a/build_tools/azure/install.cmd b/build_tools/azure/install.cmd
@@ -11,7 +11,7 @@ IF "%PYTHON_ARCH%"=="64" (
     call deactivate
     @rem Clean up any left-over from a previous build
     conda remove --all -q -y -n %VIRTUALENV%
-    conda create -n %VIRTUALENV% -q -y python=%PYTHON_VERSION% numpy scipy cython pytest wheel pillow joblib
+    conda create -n %VIRTUALENV% -q -y python=%PYTHON_VERSION% numpy scipy cython matplotlib pytest wheel pillow joblib
 
     call activate %VIRTUALENV%
 ) else (

diff --git a/doc/conf.py b/doc/conf.py
@@ -263,9 +263,9 @@
                    'sphx_glr_plot_compare_methods_001.png': 349}
 
 
-# enable experimental module so that the new GBDTs estimators can be
+# enable experimental module so that experimental estimators can be
 # discovered properly by sphinx
-from sklearn.experimental import enable_hist_gradient_boosting  # noqa
+from sklearn.experimental import *  # noqa
 
 
 def make_carousel_thumbs(app, exception):

diff --git a/doc/developers/contributing.rst b/doc/developers/contributing.rst
@@ -195,67 +195,67 @@ The preferred way to contribute to scikit-learn is to fork the `main
 repository <https://github.com/scikit-learn/scikit-learn/>`__ on GitHub,
 then submit a "pull request" (PR):
 
- 1. `Create an account <https://github.com/join>`_ on
-    GitHub if you do not already have one.
+1. `Create an account <https://github.com/join>`_ on
+   GitHub if you do not already have one.
 
- 2. Fork the `project repository
-    <https://github.com/scikit-learn/scikit-learn>`__: click on the 'Fork'
-    button near the top of the page. This creates a copy of the code under your
-    account on the GitHub user account. For more details on how to fork a
-    repository see `this guide <https://help.github.com/articles/fork-a-repo/>`_.
+2. Fork the `project repository
+   <https://github.com/scikit-learn/scikit-learn>`__: click on the 'Fork'
+   button near the top of the page. This creates a copy of the code under your
+   account on the GitHub user account. For more details on how to fork a
+   repository see `this guide <https://help.github.com/articles/fork-a-repo/>`_.
 
- 3. Clone your fork of the scikit-learn repo from your GitHub account to your
-    local disk::
+3. Clone your fork of the scikit-learn repo from your GitHub account to your
+   local disk::
 
-        $ git clone git@github.com:YourLogin/scikit-learn.git
-        $ cd scikit-learn
+       $ git clone git@github.com:YourLogin/scikit-learn.git
+       $ cd scikit-learn
 
- 4. Install library in editable mode::
+4. Install library in editable mode::
 
-        $ pip install --editable .
+       $ pip install --editable .
 
-    for more details about advanced installation, see the
-    :ref:`install_bleeding_edge` section.
+   for more details about advanced installation, see the
+   :ref:`install_bleeding_edge` section.
 
- 5. Create a branch to hold your development changes::
+5. Create a branch to hold your development changes::
 
-        $ git checkout -b my-feature
+       $ git checkout -b my-feature
 
-    and start making changes. Always use a ``feature`` branch. It's good practice to
-    never work on the ``master`` branch!
+   and start making changes. Always use a ``feature`` branch. It's good practice to
+   never work on the ``master`` branch!
 
-.. note::
+   .. note::
 
-  In the above setup, your ``origin`` remote repository points to
-  ``YourLogin/scikit-learn.git``. If you wish to fetch/merge from the main
-  repository instead of your forked one, you will need to add another remote
-  to use instead of ``origin``. If we choose the name ``upstream`` for it, the
-  command will be::
+     In the above setup, your ``origin`` remote repository points to
+     ``YourLogin/scikit-learn.git``. If you wish to fetch/merge from the main
+     repository instead of your forked one, you will need to add another remote
+     to use instead of ``origin``. If we choose the name ``upstream`` for it, the
+     command will be::
 
-        $ git remote add upstream https://github.com/scikit-learn/scikit-learn.git
+         $ git remote add upstream https://github.com/scikit-learn/scikit-learn.git
 
-  And in order to fetch the new remote and base your work on the latest changes
-  of it you can::
+     And in order to fetch the new remote and base your work on the latest changes
+     of it you can::
 
-        $ git fetch upstream
-        $ git checkout -b my-feature upstream/master
+         $ git fetch upstream
+         $ git checkout -b my-feature upstream/master
 
- 6. Develop the feature on your feature branch on your computer, using Git to do the
-    version control. When you're done editing, add changed files using ``git add``
-    and then ``git commit`` files::
+6. Develop the feature on your feature branch on your computer, using Git to do the
+   version control. When you're done editing, add changed files using ``git add``
+   and then ``git commit`` files::
 
-        $ git add modified_files
-        $ git commit
+       $ git add modified_files
+       $ git commit
 
-    to record your changes in Git, then push the changes to your GitHub account with::
+   to record your changes in Git, then push the changes to your GitHub account with::
 
-        $ git push -u origin my-feature
+       $ git push -u origin my-feature
 
- 7. Follow `these
-    <https://help.github.com/articles/creating-a-pull-request-from-a-fork>`_
-    instructions to create a pull request from your fork. This will send an
-    email to the committers. You may want to consider sending an email to the
-    mailing list for more visibility.
+7. Follow `these
+   <https://help.github.com/articles/creating-a-pull-request-from-a-fork>`_
+   instructions to create a pull request from your fork. This will send an
+   email to the committers. You may want to consider sending an email to the
+   mailing list for more visibility.
 
 .. note::
 
@@ -626,7 +626,7 @@ reviewing pull requests, you may find :ref:`this tip
 .. _testing_coverage:
 
 Testing and improving test coverage
-------------------------------------
+-----------------------------------
 
 High-quality `unit testing <https://en.wikipedia.org/wiki/Unit_testing>`_
 is a corner-stone of the scikit-learn development process. For this
@@ -641,22 +641,42 @@ the corresponding subpackages.
 
 We expect code coverage of new features to be at least around 90%.
 
-.. note:: **Workflow to improve test coverage**
+For guidelines on how to use ``pytest`` efficiently, see the
+:ref:`pytest_tips`.
 
-   To test code coverage, you need to install the `coverage
-   <https://pypi.org/project/coverage/>`_ package in addition to pytest.
+Writing matplotlib related tests
+................................
 
-   1. Run 'make test-coverage'. The output lists for each file the line
-      numbers that are not tested.
+Test fixtures ensure that a set of tests will be executing with the appropriate
+initialization and cleanup. The scikit-learn test suite implements a fixture
+which can be used with ``matplotlib``.
 
-   2. Find a low hanging fruit, looking at which lines are not tested,
-      write or adapt a test specifically for these lines.
+``pyplot``
+    The ``pyplot`` fixture should be used when a test function is dealing with
+    ``matplotlib``. ``matplotlib`` is a soft dependency and is not required.
+    This fixture is in charge of skipping the tests if ``matplotlib`` is not
+    installed. In addition, figures created during the tests will be
+    automatically closed once the test function has been executed.
 
-   3. Loop.
+To use this fixture in a test function, one needs to pass it as an
+argument::
 
-For guidelines on how to use ``pytest`` efficiently, see the
-:ref:`pytest_tips`.
+    def test_requiring_mpl_fixture(pyplot):
+        # you can now safely use matplotlib
+
+Workflow to improve test coverage
+.................................
+
+To test code coverage, you need to install the `coverage
+<https://pypi.org/project/coverage/>`_ package in addition to pytest.
+
+1. Run 'make test-coverage'. The output lists for each file the line
+    numbers that are not tested.
+
+2. Find a low hanging fruit, looking at which lines are not tested,
+    write or adapt a test specifically for these lines.
 
+3. Loop.
 
 Developers web site
 -------------------

diff --git a/doc/modules/classes.rst b/doc/modules/classes.rst
@@ -471,6 +471,7 @@ Samples generator
    :toctree: generated/
 
    experimental.enable_hist_gradient_boosting
+   experimental.enable_iterative_imputer
 
 
 .. _feature_extraction_ref:

diff --git a/doc/modules/impute.rst b/doc/modules/impute.rst
@@ -105,7 +105,16 @@ of ``y``.  This is done for each feature in an iterative fashion, and then is
 repeated for ``max_iter`` imputation rounds. The results of the final
 imputation round are returned.
 
+.. note::
+
+   This estimator is still **experimental** for now: the predictions
+   and the API might change without any deprecation cycle. To use it,
+   you need to explicitly import ``enable_iterative_imputer``.
+
+::
+
     >>> import numpy as np
+    >>> from sklearn.experimental import enable_iterative_imputer
     >>> from sklearn.impute import IterativeImputer
     >>> imp = IterativeImputer(max_iter=10, random_state=0)
     >>> imp.fit([[1, 2], [3, 6], [4, 8], [np.nan, 3], [7, np.nan]])  # doctest: +NORMALIZE_WHITESPACE

diff --git a/doc/modules/linear_model.rst b/doc/modules/linear_model.rst
@@ -136,17 +136,24 @@ Setting the regularization parameter: generalized Cross-Validation
 ------------------------------------------------------------------
 
 :class:`RidgeCV` implements ridge regression with built-in
-cross-validation of the alpha parameter.  The object works in the same way
+cross-validation of the alpha parameter. The object works in the same way
 as GridSearchCV except that it defaults to Generalized Cross-Validation
 (GCV), an efficient form of leave-one-out cross-validation::
 
+    >>> import numpy as np
     >>> from sklearn import linear_model
-    >>> reg = linear_model.RidgeCV(alphas=[0.1, 1.0, 10.0], cv=3)
-    >>> reg.fit([[0, 0], [0, 0], [1, 1]], [0, .1, 1])       # doctest: +SKIP
-    RidgeCV(alphas=[0.1, 1.0, 10.0], cv=3, fit_intercept=True, scoring=None,
-        normalize=False)
-    >>> reg.alpha_                                      # doctest: +SKIP
-    0.1
+    >>> reg = linear_model.RidgeCV(alphas=np.logspace(-6, 6, 13))
+    >>> reg.fit([[0, 0], [0, 0], [1, 1]], [0, .1, 1])       # doctest: +NORMALIZE_WHITESPACE
+    RidgeCV(alphas=array([1.e-06, 1.e-05, 1.e-04, 1.e-03, 1.e-02, 1.e-01, 1.e+00, 1.e+01,
+          1.e+02, 1.e+03, 1.e+04, 1.e+05, 1.e+06]),
+            cv=None, fit_intercept=True, gcv_mode=None, normalize=False,
+            scoring=None, store_cv_values=False)
+    >>> reg.alpha_
+    0.01
+
+Specifying the value of the `cv` attribute will trigger the use of
+cross-validation with `GridSearchCV`, for example `cv=10` for 10-fold
+cross-validation, rather than Generalized Cross-Validation.
 
 .. topic:: References
 

diff --git a/doc/roadmap.rst b/doc/roadmap.rst
@@ -128,7 +128,6 @@ bottom.
 
 #. Improved tools for model diagnostics and basic inference
 
-   * partial dependence plots :issue:`5653`
    * alternative feature importances implementations (e.g. methods or wrappers)
    * better ways to handle validation sets when fitting
    * better ways to find thresholds / create decision rules :issue:`8614`
@@ -144,19 +143,6 @@ bottom.
      :issue:`6929`
    * Callbacks or a similar system would facilitate logging and early stopping
 
-#. Use scipy BLAS Cython bindings
-
-   * This will make it possible to get rid of our partial copy of suboptimal
-     Atlas C-routines. :issue:`11638`
-   * This should speed up the Windows and Linux wheels
-
-#. Allow fine-grained parallelism in cython
-
-   * Now that we do not use fork-based multiprocessing in joblib anymore it's
-     possible to use the prange / openmp thread management which makes it
-     possible to have very efficient thread-based parallelism at the Cython
-     level. Example with K-Means: :issue:`11950`
-
 #. Distributed parallelism
 
    * Joblib can now plug onto several backends, some of them can distribute the
@@ -240,9 +226,6 @@ Subpackage-specific goals
 :mod:`sklearn.ensemble`
 
 * a stacking implementation
-* a binned feature histogram based and thread parallel implementation of
-  decision trees to compete with the performance of state of the art gradient
-  boosting like LightGBM.
 
 :mod:`sklearn.model_selection`
 
@@ -269,5 +252,3 @@ Subpackage-specific goals
 
 * Performance issues with `Pipeline.memory`
 * see "Everything in Scikit-learn should conform to our API contract" above
-* Add a verbose option :issue:`10435`
-