Merge pull request numpy#19911 from DimitriPapadopoulos/codespell

DOC: Typos found by codespell

Author: seberg

doc/preprocess.py

@@ -9,7 +9,7 @@ def main():
 
 def doxy_gen(root_path):
     """
-    Generate Doxygen configration file.
+    Generate Doxygen configuration file.
     """
     confs = doxy_config(root_path)
     build_path = os.path.join(root_path, "doc", "build", "doxygen")

doc/source/dev/development_advanced_debugging.rst

@@ -3,8 +3,8 @@ Advanced debugging tools
 ========================
 
 If you reached here, you want to dive into, or use, more advanced tooling.
-This is usually not necessary for first time contributers and most
-day-to-day developement.
+This is usually not necessary for first time contributors and most
+day-to-day development.
 These are used more rarely, for example close to a new NumPy release,
 or when a large or particular complex change was made.
 
@@ -25,7 +25,7 @@ narrow down.
 We do not expect any of these tools to be run by most contributors.
 However, you can ensure that we can track down such issues more easily easier:
 
-* Tests should cover all code paths, incluing error paths.
+* Tests should cover all code paths, including error paths.
 * Try to write short and simple tests. If you have a very complicated test
   consider creating an additional simpler test as well.
   This can be helpful, because often it is only easy to find which test
@@ -112,7 +112,7 @@ where ``PYTHONMALLOC=malloc`` is necessary to avoid false positives from python
 itself.
 Depending on the system and valgrind version, you may see more false positives.
 ``valgrind`` supports "suppressions" to ignore some of these, and Python does
-have a supression file (and even a compile time option) which may help if you
+have a suppression file (and even a compile time option) which may help if you
 find it necessary.
 
 Valgrind helps:

doc/source/dev/development_environment.rst

@@ -122,7 +122,7 @@ source tree is to use::
 
 
 NumPy uses a series of tests to probe the compiler and libc libraries for
-funtions. The results are stored in ``_numpyconfig.h`` and ``config.h`` files
+functions. The results are stored in ``_numpyconfig.h`` and ``config.h`` files
 using ``HAVE_XXX`` definitions. These tests are run during the ``build_src``
 phase of the ``_multiarray_umath`` module in the ``generate_config_h`` and
 ``generate_numpyconfig_h`` functions. Since the output of these calls includes

doc/source/dev/howto-docs.rst

@@ -60,7 +60,7 @@ category, but other rewordings -- even for grammar -- require a judgment call,
 which raises the bar. Test the waters by first presenting the fix as an issue.
 
 Some functions/objects like numpy.ndarray.transpose, numpy.array etc. defined in
-C-extension modules have their docstrings defined seperately in `_add_newdocs.py
+C-extension modules have their docstrings defined separately in `_add_newdocs.py
 <https://github.com/numpy/numpy/blob/main/numpy/core/_add_newdocs.py>`__
 
 **********************
@@ -72,7 +72,7 @@ Your frustrations using our documents are our best guide to what needs fixing.
 If you write a missing doc you join the front line of open source, but it's
 a meaningful contribution just to let us know what's missing. If you want to
 compose a doc, run your thoughts by the `mailing list
-<https://mail.python.org/mailman/listinfo/numpy-discussion>`__ for futher
+<https://mail.python.org/mailman/listinfo/numpy-discussion>`__ for further
 ideas and feedback. If you want to alert us to a gap,
 `open an issue <https://github.com/numpy/numpy/issues>`__. See
 `this issue <https://github.com/numpy/numpy/issues/15760>`__ for an example.

doc/source/reference/arrays.scalars.rst

@@ -399,7 +399,7 @@ are also provided.
                complex256
 
    Alias for `numpy.clongdouble`, named after its size in bits.
-   The existance of these aliases depends on the platform.
+   The existence of these aliases depends on the platform.
 
 Other aliases
 ~~~~~~~~~~~~~

doc/source/reference/c-api/iterator.rst

@@ -1230,7 +1230,7 @@ Functions For Iteration
 .. c:function:: npy_intp* NpyIter_GetIndexPtr(NpyIter* iter)
 
     This gives back a pointer to the index being tracked, or NULL
-    if no index is being tracked.  It is only useable if one of
+    if no index is being tracked.  It is only usable if one of
     the flags :c:data:`NPY_ITER_C_INDEX` or :c:data:`NPY_ITER_F_INDEX`
     were specified during construction.
 

doc/source/reference/c-api/types-and-structures.rst

@@ -94,7 +94,7 @@ PyArray_Type and PyArrayObject
           PyArray_Descr *descr;
           int flags;
           PyObject *weakreflist;
-          /* version dependend private members */
+          /* version dependent private members */
       } PyArrayObject;
 
    .. c:macro:: PyObject_HEAD
@@ -178,7 +178,7 @@ PyArray_Type and PyArrayObject
 
    .. note::
 
-      Further members are considered private and version dependend. If the size
+      Further members are considered private and version dependent. If the size
       of the struct is important for your code, special care must be taken.
       A possible use-case when this is relevant is subclassing in C.
       If your code relies on ``sizeof(PyArrayObject)`` to be constant,

doc/source/reference/random/bit_generators/index.rst

@@ -4,7 +4,7 @@ Bit Generators
 --------------
 
 The random values produced by :class:`~Generator`
-orignate in a BitGenerator.  The BitGenerators do not directly provide
+originate in a BitGenerator.  The BitGenerators do not directly provide
 random numbers and only contains methods used for seeding, getting or
 setting the state, jumping or advancing the state, and for accessing
 low-level wrappers for consumption by code that can efficiently

doc/source/reference/routines.ma.rst

@@ -287,11 +287,11 @@ Filling a masked array
 
 _____
 
-Masked arrays arithmetics
-=========================
+Masked arrays arithmetic
+========================
 
-Arithmetics
-~~~~~~~~~~~
+Arithmetic
+~~~~~~~~~~
 .. autosummary::
    :toctree: generated/
 

doc/source/reference/routines.polynomials.rst

@@ -22,7 +22,7 @@ Therefore :mod:`numpy.polynomial` is recommended for new coding.
    the polynomial functions prefixed with *poly* accessible from the `numpy`
    namespace (e.g. `numpy.polyadd`, `numpy.polyval`, `numpy.polyfit`, etc.).
 
-   The term *polynomial package* refers to the new API definied in 
+   The term *polynomial package* refers to the new API defined in 
    `numpy.polynomial`, which includes the convenience classes for the
    different kinds of polynomials (`numpy.polynomial.Polynomial`,
    `numpy.polynomial.Chebyshev`, etc.).
@@ -110,7 +110,7 @@ See the documentation for the
 `convenience classes <routines.polynomials.classes>`_ for further details on
 the ``domain`` and ``window`` attributes.
 
-Another major difference bewteen the legacy polynomial module and the
+Another major difference between the legacy polynomial module and the
 polynomial package is polynomial fitting. In the old module, fitting was
 done via the `~numpy.polyfit` function. In the polynomial package, the
 `~numpy.polynomial.polynomial.Polynomial.fit` class method is preferred. For