DOC: Typos found by codespell

8 files changed, 20 insertions, 20 deletions

diff --git a/doc/source/reference/arrays.scalars.rst b/doc/source/reference/arrays.scalars.rst
index abef66692..ccab0101e 100644
--- a/doc/source/reference/arrays.scalars.rst
+++ b/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
 ~~~~~~~~~~~~~
diff --git a/doc/source/reference/c-api/iterator.rst b/doc/source/reference/c-api/iterator.rst
index 2208cdd2f..83644d8b2 100644
--- a/doc/source/reference/c-api/iterator.rst
+++ b/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.
 
diff --git a/doc/source/reference/c-api/types-and-structures.rst b/doc/source/reference/c-api/types-and-structures.rst
index 39a17cc72..36293ce99 100644
--- a/doc/source/reference/c-api/types-and-structures.rst
+++ b/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,
diff --git a/doc/source/reference/random/bit_generators/index.rst b/doc/source/reference/random/bit_generators/index.rst
index c5c349806..211f0d60e 100644
--- a/doc/source/reference/random/bit_generators/index.rst
+++ b/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
diff --git a/doc/source/reference/routines.ma.rst b/doc/source/reference/routines.ma.rst
index d961cbf02..2db325293 100644
--- a/doc/source/reference/routines.ma.rst
+++ b/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/
 
diff --git a/doc/source/reference/routines.polynomials.rst b/doc/source/reference/routines.polynomials.rst
index ecfb012f0..4aea963c0 100644
--- a/doc/source/reference/routines.polynomials.rst
+++ b/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
diff --git a/doc/source/reference/simd/simd-optimizations.rst b/doc/source/reference/simd/simd-optimizations.rst
index 956824321..9de6d1734 100644
--- a/doc/source/reference/simd/simd-optimizations.rst
+++ b/doc/source/reference/simd/simd-optimizations.rst
@@ -14,7 +14,7 @@ written only once. There are three layers:
   written using the maximum set of intrinsics possible.
 - At *compile* time, a distutils command is used to define the minimum and
   maximum features to support, based on user choice and compiler support. The
-  appropriate macros are overlayed with the platform / architecture intrinsics,
+  appropriate macros are overlaid with the platform / architecture intrinsics,
   and the three loops are compiled.
 - At *runtime import*, the CPU is probed for the set of supported intrinsic
   features. A mechanism is used to grab the pointer to the most appropriate
@@ -89,7 +89,7 @@ NOTES
 ~~~~~~~~~~~~~
 - CPU features and other options are case-insensitive.
 
-- The order of the requsted optimizations doesn't matter.
+- The order of the requested optimizations doesn't matter.
 
 - Either commas or spaces can be used as a separator, e.g. ``--cpu-dispatch``\ =
   "avx2 avx512f" or ``--cpu-dispatch``\ = "avx2, avx512f" both work, but the
@@ -113,7 +113,7 @@ NOTES
   compiler native flag ``-march=native`` or ``-xHost`` or ``QxHost`` is
   enabled through environment variable ``CFLAGS``
 
-- The validation process for the requsted optimizations when it comes to
+- The validation process for the requested optimizations when it comes to
   ``--cpu-baseline`` isn't strict. For example, if the user requested
   ``AVX2`` but the compiler doesn't support it then we just skip it and return
   the maximum optimization that the compiler can handle depending on the
@@ -379,15 +379,15 @@ through ``--cpu-dispatch``, but it can also represent other options such as:
       #include "numpy/utils.h" // NPY_CAT, NPY_TOSTR
 
       #ifndef NPY__CPU_TARGET_CURRENT
-        // wrapping the dispatch-able source only happens to the addtional optimizations
-        // but if the keyword 'baseline' provided within the configuration statments,
+        // wrapping the dispatch-able source only happens to the additional optimizations
+        // but if the keyword 'baseline' provided within the configuration statements,
         // the infrastructure will add extra compiling for the dispatch-able source by
         // passing it as-is to the compiler without any changes.
         #define CURRENT_TARGET(X) X
         #define NPY__CPU_TARGET_CURRENT baseline // for printing only
       #else
         // since we reach to this point, that's mean we're dealing with
-          // the addtional optimizations, so it could be SSE42 or AVX512F
+          // the additional optimizations, so it could be SSE42 or AVX512F
         #define CURRENT_TARGET(X) NPY_CAT(NPY_CAT(X, _), NPY__CPU_TARGET_CURRENT)
       #endif
       // Macro 'CURRENT_TARGET' adding the current target as suffux to the exported symbols,
@@ -418,7 +418,7 @@ through ``--cpu-dispatch``, but it can also represent other options such as:
       #undef NPY__CPU_DISPATCH_BASELINE_CALL
       #undef NPY__CPU_DISPATCH_CALL
       // nothing strange here, just a normal preprocessor callback
-      // enabled only if 'baseline' spesfied withiin the configration statments
+      // enabled only if 'baseline' specified within the configuration statements
       #define NPY__CPU_DISPATCH_BASELINE_CALL(CB, ...) \
         NPY__CPU_DISPATCH_EXPAND_(CB(__VA_ARGS__))
       // 'NPY__CPU_DISPATCH_CALL' is an abstract macro is used for dispatching
@@ -427,7 +427,7 @@ through ``--cpu-dispatch``, but it can also represent other options such as:
       // @param CHK, Expected a macro that can be used to detect CPU features
       // in runtime, which takes a CPU feature name without string quotes and
       // returns the testing result in a shape of boolean value.
-      // NumPy already has macro called "NPY_CPU_HAVE", which fit this requirment.
+      // NumPy already has macro called "NPY_CPU_HAVE", which fits this requirement.
       //
       // @param CB, a callback macro that expected to be called multiple times depending
       // on the required optimizations, the callback should receive the following arguments:
diff --git a/doc/source/reference/ufuncs.rst b/doc/source/reference/ufuncs.rst
index b832dad04..6ace5b233 100644
--- a/doc/source/reference/ufuncs.rst
+++ b/doc/source/reference/ufuncs.rst
@@ -185,7 +185,7 @@ attribute of the ufunc.  (This list may be missing DTypes not defined
 by NumPy.)
 
 The ``signature`` only specifies the DType class/type.  For example, it
-can specifiy that the operation should be ``datetime64`` or ``float64``
+can specify that the operation should be ``datetime64`` or ``float64``
 operation.  It does not specify the ``datetime64`` time-unit or the
 ``float64`` byte-order.