DOC phrasing improvements and typos (scikit-learn#16744)

Author: raduspaimoc

doc/about.rst

@@ -13,7 +13,7 @@ this project as part of his thesis.
 In 2010 Fabian Pedregosa, Gael Varoquaux, Alexandre Gramfort and Vincent
 Michel of INRIA took leadership of the project and made the first public
 release, February the 1st 2010. Since then, several releases have appeared
-following a ~3 month cycle, and a thriving international community has
+following a ~ 3-month cycle, and a thriving international community has
 been leading the development.
 
 Governance
@@ -520,7 +520,7 @@ budget of the project [#f1]_.
 
 .. rubric:: Notes
 
-.. [#f1] Regarding the organization budget in particular, we might use some of
+.. [#f1] Regarding the organization budget, in particular, we might use some of
          the donated funds to pay for other project expenses such as DNS,
          hosting or continuous integration services.
 

doc/faq.rst

@@ -97,7 +97,7 @@ What are the inclusion criteria for new algorithms ?
 ----------------------------------------------------
 
 We only consider well-established algorithms for inclusion. A rule of thumb is
-at least 3 years since publication, 200+ citations and wide use and
+at least 3 years since publication, 200+ citations, and wide use and
 usefulness. A technique that provides a clear-cut improvement (e.g. an
 enhanced data structure or a more efficient approximation technique) on
 a widely-used method will also be considered for inclusion.
@@ -123,7 +123,7 @@ Inclusion of a new algorithm speeding up an existing model is easier if:
   n_samples",
 - benchmarks clearly show a speed up.
 
-Also note that your implementation need not be in scikit-learn to be used
+Also, note that your implementation need not be in scikit-learn to be used
 together with scikit-learn tools. You can implement your favorite algorithm
 in a scikit-learn compatible way, upload it to GitHub and let us know. We
 will be happy to list it under :ref:`related_projects`. If you already have
@@ -135,7 +135,7 @@ interested to look at `scikit-learn-contrib
 
 Why are you so selective on what algorithms you include in scikit-learn?
 ------------------------------------------------------------------------
-Code is maintenance cost, and we need to balance the amount of
+Code comes with maintenance cost, and we need to balance the amount of
 code we have with the size of the team (and add to this the fact that
 complexity scales non linearly with the number of features).
 The package relies on core developers using their free time to
@@ -250,7 +250,7 @@ Why do I sometime get a crash/freeze with n_jobs > 1 under OSX or Linux?
 
 Several scikit-learn tools such as ``GridSearchCV`` and ``cross_val_score``
 rely internally on Python's `multiprocessing` module to parallelize execution
-onto several Python processes by passing ``n_jobs > 1`` as argument.
+onto several Python processes by passing ``n_jobs > 1`` as an argument.
 
 The problem is that Python ``multiprocessing`` does a ``fork`` system call
 without following it with an ``exec`` system call for performance reasons. Many

doc/glossary.rst

@@ -41,7 +41,7 @@ General Concepts
         contributor documentation <api_overview>`.
 
         The specific interfaces that constitute Scikit-learn's public API are
-        largely documented in :ref:`api_ref`. However we less formally consider
+        largely documented in :ref:`api_ref`. However, we less formally consider
         anything as public API if none of the identifiers required to access it
         begins with ``_``.  We generally try to maintain :term:`backwards
         compatibility` for all objects in the public API.
@@ -106,12 +106,12 @@ General Concepts
         are documented under an estimator's *Parameters* documentation.
 
     backwards compatibility
-        We generally try to maintain backwards compatibility (i.e. interfaces
+        We generally try to maintain backward compatibility (i.e. interfaces
         and behaviors may be extended but not changed or removed) from release
         to release but this comes with some exceptions:
 
         Public API only
-            The behaviour of objects accessed through private identifiers
+            The behavior of objects accessed through private identifiers
             (those beginning ``_``) may be changed arbitrarily between
             versions.
         As documented
@@ -145,8 +145,8 @@ General Concepts
             assumed but not formally tested.
 
         Despite this informal contract with our users, the software is provided
-        as is, as stated in the licence.  When a release inadvertently
-        introduces changes that are not backwards compatible, these are known
+        as is, as stated in the license.  When a release inadvertently
+        introduces changes that are not backward compatible, these are known
         as software regressions.
 
     callable
@@ -647,7 +647,7 @@ General Concepts
         first axis and a fixed, finite set of :term:`features` on the second
         is called rectangular.
 
-        This term excludes samples with non-vectorial structure, such as text,
+        This term excludes samples with non-vectorial structures, such as text,
         an image of arbitrary size, a time series of arbitrary length, a set of
         vectors, etc. The purpose of a :term:`vectorizer` is to produce
         rectangular forms of such data.
@@ -684,7 +684,7 @@ General Concepts
         versions happen via a :ref:`SLEP <slep>` and follows the
         decision-making process outlined in :ref:`governance`.
         For all votes, a proposal must have been made public and discussed before the
-        vote. Such proposal must be a consolidated document, in the form of a
+        vote. Such a proposal must be a consolidated document, in the form of a
         ‘Scikit-Learn Enhancement Proposal’ (SLEP), rather than a long discussion on an
         issue. A SLEP must be submitted as a pull-request to
         `enhancement proposals <https://scikit-learn-enhancement-proposals.readthedocs.io>`_ using the
@@ -881,12 +881,12 @@ Class APIs and Estimator Types
         In a meta-estimator's :term:`fit` method, any contained estimators
         should be :term:`cloned` before they are fit (although FIXME: Pipeline
         and FeatureUnion do not do this currently). An exception to this is
-        that an estimator may explicitly document that it accepts a prefitted
+        that an estimator may explicitly document that it accepts a pre-fitted
         estimator (e.g. using ``prefit=True`` in
         :class:`feature_selection.SelectFromModel`). One known issue with this
-        is that the prefitted estimator will lose its model if the
+        is that the pre-fitted estimator will lose its model if the
         meta-estimator is cloned.  A meta-estimator should have ``fit`` called
-        before prediction, even if all contained estimators are prefitted.
+        before prediction, even if all contained estimators are pre-fitted.
 
         In cases where a meta-estimator's primary behaviors (e.g.
         :term:`predict` or :term:`transform` implementation) are functions of
@@ -1008,7 +1008,7 @@ Target Types
 
     binary
         A classification problem consisting of two classes.  A binary target
-        may represented as for a :term:`multiclass` problem but with only two
+        may  be represented as for a :term:`multiclass` problem but with only two
         labels.  A binary decision function is represented as a 1d array.
 
         Semantically, one class is often considered the "positive" class.
@@ -1028,7 +1028,7 @@ Target Types
 
     continuous
         A regression problem where each sample's target is a finite floating
-        point number, represented as a 1-dimensional array of floats (or
+        point number represented as a 1-dimensional array of floats (or
         sometimes ints).
 
         :func:`~utils.multiclass.type_of_target` will return 'continuous' for
@@ -1078,7 +1078,7 @@ Target Types
         A classification problem where each sample's target consists of
         ``n_outputs`` :term:`outputs`, each a class label, for a fixed int
         ``n_outputs > 1`` in a particular dataset.  Each output has a
-        fixed set of available classes, and each sample is labelled with a
+        fixed set of available classes, and each sample is labeled with a
         class for each output. An output may be binary or multiclass, and in
         the case where all outputs are binary, the target is
         :term:`multilabel`.
@@ -1213,10 +1213,10 @@ Methods
         and ``transform`` separately would be less efficient than together.
         :class:`base.TransformerMixin` provides a default implementation,
         providing a consistent interface across transformers where
-        ``fit_transform`` is or is not specialised.
+        ``fit_transform`` is or is not specialized.
 
         In :term:`inductive` learning -- where the goal is to learn a
-        generalised model that can be applied to new data -- users should be
+        generalized model that can be applied to new data -- users should be
         careful not to apply ``fit_transform`` to the entirety of a dataset
         (i.e. training and test data together) before further modelling, as
         this results in :term:`data leakage`.
@@ -1225,7 +1225,7 @@ Methods
         Primarily for :term:`feature extractors`, but also used for other
         transformers to provide string names for each column in the output of
         the estimator's :term:`transform` method.  It outputs a list of
-        strings, and may take a list of strings as input, corresponding
+        strings and may take a list of strings as input, corresponding
         to the names of input columns from which output column names can
         be generated.  By default input features are named x0, x1, ....
 
@@ -1250,7 +1250,7 @@ Methods
     ``partial_fit``
         Facilitates fitting an estimator in an online fashion.  Unlike ``fit``,
         repeatedly calling ``partial_fit`` does not clear the model, but
-        updates it with respect to the data provided. The portion of data
+        updates it with the data provided. The portion of data
         provided to ``partial_fit`` may be called a mini-batch.
         Each mini-batch must be of consistent shape, etc. In iterative
         estimators, ``partial_fit`` often only performs a single iteration.
@@ -1322,7 +1322,7 @@ Methods
         to facilitate numerical stability.
 
     ``predict_proba``
-        A method in :term:`classifiers` and :term:`clusterers` that are able to
+        A method in :term:`classifiers` and :term:`clusterers` that can
         return probability estimates for each class/cluster.  Its input is
         usually only some observed data, :term:`X`.
 
@@ -1381,7 +1381,7 @@ Methods
         In a :term:`transformer`, transforms the input, usually only :term:`X`,
         into some transformed space (conventionally notated as :term:`Xt`).
         Output is an array or sparse matrix of length :term:`n_samples` and
-        with number of columns fixed after :term:`fitting`.
+        with the number of columns fixed after :term:`fitting`.
 
         If the estimator was not already :term:`fitted`, calling this method
         should raise a :class:`exceptions.NotFittedError`.
@@ -1405,8 +1405,8 @@ functions or non-estimator constructors.
         :term:`multioutput` (including :term:`multilabel`) tasks, the weights
         are multiplied across outputs (i.e. columns of ``y``).
 
-        By default all samples have equal weight such that classes are
-        effectively weighted by their their prevalence in the training data.
+        By default, all samples have equal weight such that classes are
+        effectively weighted by their prevalence in the training data.
         This could be achieved explicitly with ``class_weight={label1: 1,
         label2: 1, ...}`` for all class labels.
 
@@ -1581,10 +1581,11 @@ functions or non-estimator constructors.
         in the User Guide.
 
         Where multiple metrics can be evaluated, ``scoring`` may be given
-        either as a list of unique strings or a dict with names as keys and
-        callables as values. Note that this does *not* specify which score
-        function is to be maximised, and another parameter such as ``refit``
-        may be used for this purpose.
+        either as a list of unique strings or a dictionary with names as keys
+        and callables as values. Note that this does *not* specify which score
+        function is to be maximized, and another parameter such as ``refit``
+        maybe used for this purpose.
+
 
         The ``scoring`` parameter is validated and interpreted using
         :func:`metrics.check_scoring`.
@@ -1604,9 +1605,9 @@ functions or non-estimator constructors.
         When fitting an estimator repeatedly on the same dataset, but for
         multiple parameter values (such as to find the value maximizing
         performance as in :ref:`grid search <grid_search>`), it may be possible
-        to reuse aspects of the model learnt from the previous parameter value,
+        to reuse aspects of the model learned from the previous parameter value,
         saving time.  When ``warm_start`` is true, the existing :term:`fitted`
-        model :term:`attributes` are used to initialise the new model
+        model :term:`attributes` are used to initialize the new model
         in a subsequent call to :term:`fit`.
 
         Note that this is only applicable for some models and some
@@ -1701,8 +1702,8 @@ See concept :term:`sample property`.
 .. glossary::
 
     ``groups``
-        Used in cross validation routines to identify samples which are
-        correlated.  Each value is an identifier such that, in a supporting
+        Used in cross-validation routines to identify samples that are correlated.
+        Each value is an identifier such that, in a supporting
         :term:`CV splitter`, samples from some ``groups`` value may not
         appear in both a training set and its corresponding test set.
         See :ref:`group_cv`.