8 files changed, 9 insertions, 9 deletions

diff --git a/doc/source/dev/gitwash/development_setup.rst b/doc/source/dev/gitwash/development_setup.rst
index 2be7125da..a2fc61d2e 100644
--- a/doc/source/dev/gitwash/development_setup.rst
+++ b/doc/source/dev/gitwash/development_setup.rst
@@ -112,7 +112,7 @@ Look it over
    - the ``main`` branch you just cloned on your own machine
    - the ``main`` branch from your fork on GitHub, which git named
      ``origin`` by default
-   - the ``main`` branch on the the main NumPy repo, which you named
+   - the ``main`` branch on the main NumPy repo, which you named
      ``upstream``.
 
    ::
diff --git a/doc/source/reference/c-api/iterator.rst b/doc/source/reference/c-api/iterator.rst
index 83644d8b2..b4adaef9b 100644
--- a/doc/source/reference/c-api/iterator.rst
+++ b/doc/source/reference/c-api/iterator.rst
@@ -653,7 +653,7 @@ Construction and Destruction
     may not be repeated.  The following example is how normal broadcasting
     applies to a 3-D array, a 2-D array, a 1-D array and a scalar.
 
-    **Note**: Before NumPy 1.8 ``oa_ndim == 0` was used for signalling that
+    **Note**: Before NumPy 1.8 ``oa_ndim == 0` was used for signalling
     that ``op_axes`` and ``itershape`` are unused. This is deprecated and
     should be replaced with -1. Better backward compatibility may be
     achieved by using :c:func:`NpyIter_MultiNew` for this case.
diff --git a/doc/source/reference/c-api/ufunc.rst b/doc/source/reference/c-api/ufunc.rst
index 2909ce9af..39447ae24 100644
--- a/doc/source/reference/c-api/ufunc.rst
+++ b/doc/source/reference/c-api/ufunc.rst
@@ -171,7 +171,7 @@ Functions
        `numpy.dtype.num` (built-in only) that the corresponding
        function in the ``func`` array accepts. For instance, for a comparison
        ufunc with three ``ntypes``, two ``nin`` and one ``nout``, where the
-       first function accepts `numpy.int32` and the the second
+       first function accepts `numpy.int32` and the second
        `numpy.int64`, with both returning `numpy.bool_`, ``types`` would
        be ``(char[]) {5, 5, 0, 7, 7, 0}`` since ``NPY_INT32`` is 5,
        ``NPY_INT64`` is 7, and ``NPY_BOOL`` is 0.
diff --git a/doc/source/reference/random/parallel.rst b/doc/source/reference/random/parallel.rst
index 7f0207bde..bff955948 100644
--- a/doc/source/reference/random/parallel.rst
+++ b/doc/source/reference/random/parallel.rst
@@ -28,8 +28,8 @@ streams.
 
 `~SeedSequence` avoids these problems by using successions of integer hashes
 with good `avalanche properties`_ to ensure that flipping any bit in the input
-input has about a 50% chance of flipping any bit in the output. Two input seeds
-that are very close to each other will produce initial states that are very far
+has about a 50% chance of flipping any bit in the output. Two input seeds that
+are very close to each other will produce initial states that are very far
 from each other (with very high probability). It is also constructed in such
 a way that you can provide arbitrary-sized integers or lists of integers.
 `~SeedSequence` will take all of the bits that you provide and mix them
diff --git a/doc/source/reference/swig.interface-file.rst b/doc/source/reference/swig.interface-file.rst
index 6dd74f4ec..a22b98d39 100644
--- a/doc/source/reference/swig.interface-file.rst
+++ b/doc/source/reference/swig.interface-file.rst
@@ -904,7 +904,7 @@ Routines
 
     * ``PyArrayObject* ary``, a NumPy array.
 
-    Require the given ``PyArrayObject`` to to be Fortran ordered.  If
+    Require the given ``PyArrayObject`` to be Fortran ordered.  If
     the ``PyArrayObject`` is already Fortran ordered, do nothing.
     Else, set the Fortran ordering flag and recompute the strides.
 
diff --git a/doc/source/user/basics.subclassing.rst b/doc/source/user/basics.subclassing.rst
index 55b23bb78..cee794b8c 100644
--- a/doc/source/user/basics.subclassing.rst
+++ b/doc/source/user/basics.subclassing.rst
@@ -523,7 +523,7 @@ which inputs and outputs it converted. Hence, e.g.,
 >>> a.info
 {'inputs': [0, 1], 'outputs': [0]}
 
-Note that another approach would be to to use ``getattr(ufunc,
+Note that another approach would be to use ``getattr(ufunc,
 methods)(*inputs, **kwargs)`` instead of the ``super`` call. For this example,
 the result would be identical, but there is a difference if another operand
 also defines ``__array_ufunc__``. E.g., lets assume that we evalulate
diff --git a/doc/source/user/building.rst b/doc/source/user/building.rst
index 1a1220502..f6554c5e2 100644
--- a/doc/source/user/building.rst
+++ b/doc/source/user/building.rst
@@ -341,7 +341,7 @@ intended host and not the build system, set::
 
 where ``${ARCH_TRIPLET}`` is an architecture-dependent suffix appropriate for
 the host architecture. (This should be the name of a ``_sysconfigdata`` file,
-without the ``.py`` extension, found in in the host Python library directory.)
+without the ``.py`` extension, found in the host Python library directory.)
 
 When using external linear algebra libraries, include and library directories
 should be provided for the desired libraries in ``site.cfg`` as described
diff --git a/doc/source/user/c-info.how-to-extend.rst b/doc/source/user/c-info.how-to-extend.rst
index 155d56306..ffa141b95 100644
--- a/doc/source/user/c-info.how-to-extend.rst
+++ b/doc/source/user/c-info.how-to-extend.rst
@@ -111,7 +111,7 @@ Defining functions
 ==================
 
 The second argument passed in to the Py_InitModule function is a
-structure that makes it easy to to define functions in the module. In
+structure that makes it easy to define functions in the module. In
 the example given above, the mymethods structure would have been
 defined earlier in the file (usually right before the init{name}
 subroutine) to: