DOC: Fix typos found by codespell in NEPs

* NEP 0051 is recent
* NEP 0021 is older, I don't know why the typo hadn't been previously caught

2 files changed, 7 insertions, 7 deletions

diff --git a/doc/neps/nep-0021-advanced-indexing.rst b/doc/neps/nep-0021-advanced-indexing.rst
index 7751d309b..4c7a16375 100644
--- a/doc/neps/nep-0021-advanced-indexing.rst
+++ b/doc/neps/nep-0021-advanced-indexing.rst
@@ -143,7 +143,7 @@ exactly.
 
 Vectorized indexing in particular can be challenging to implement with array
 storage backends not based on NumPy. In contrast, indexing by 1D arrays along
-at least one dimension in the style of outer indexing is much more acheivable.
+at least one dimension in the style of outer indexing is much more achievable.
 This has led many libraries (including dask and h5py) to attempt to define a
 safe subset of NumPy-style indexing that is equivalent to outer indexing, e.g.,
 by only allowing indexing with an array along at most one dimension. However,
diff --git a/doc/neps/nep-0051-scalar-representation.rst b/doc/neps/nep-0051-scalar-representation.rst
index 851f173de..1e6f27a5f 100644
--- a/doc/neps/nep-0051-scalar-representation.rst
+++ b/doc/neps/nep-0051-scalar-representation.rst
@@ -70,7 +70,7 @@ Even ``np.float64``, which is very similar to Python's ``float`` and inherits
 from it, does behave differently for example when dividing by zero.
 
 Another common source of confusion are the NumPy booleans.  Python programmers
-somtimes write ``obj is True`` and will surprised when an object that shows
+sometimes write ``obj is True`` and will surprised when an object that shows
 as ``True`` fails to pass the test.
 It is much easier to understand this behavior when the value is
 shown as ``np.True_``.
@@ -96,7 +96,7 @@ Jupyter notebook cells will often show the type information intact.
 
     np.longdouble('3.0')
 
-to allow round-tripping.  Addtionally to this change, ``float128`` will
+to allow round-tripping.  Additionally to this change, ``float128`` will
 now always be printed as ``longdouble`` since the old name gives a false
 impression of precision.
 
@@ -137,7 +137,7 @@ The proposal is to change the default (back) to use ``str`` rather than
 Detailed description
 ====================
 
-This NEP proposes to change the represenatation for NumPy scalars to:
+This NEP proposes to change the representation for NumPy scalars to:
 
 * ``np.True_`` and ``np.False_`` for booleans (their singleton instances)
 * ``np.scalar(<value>)``, i.e. ``np.float64(3.0)`` for all numerical dtypes.
@@ -202,8 +202,8 @@ to always print as ``longdouble`` and never ``float128`` or ``float96``.
 It does not include deprecating the ``np.float128`` alias.
 However, such a deprecation may occur independently of the NEP.
 
-Integer scalar type name and instance represenatation
------------------------------------------------------
+Integer scalar type name and instance representation
+----------------------------------------------------
 
 One detail is that due to NumPy scalar types being based on the C types,
 NumPy sometimes distinguishes them, for example on most 64 bit systems
@@ -263,7 +263,7 @@ allowing customized formatting for all DTypes.
 
 Making ``get_formatter`` public allows it to be used for ``np.record`` and
 masked arrays.
-Currenlty, the formatters themselves seem semi-public; using a single
+Currently, the formatters themselves seem semi-public; using a single
 entry-point will hopefully provide a clear API for formatting NumPy values.
 
 The large part for the scalar representation changes had previously been done