8000 Merge pull request #29106 from koyuki7w/patch-1 · numpy/numpy@1654bd1 · GitHub
[go: up one dir, main page]
Skip to content

Commit 1654bd1

Browse files
charrischarris
authored
Merge pull request #29106 from koyuki7w/patch-1
DOC: Fix some incorrect reST markups
2 parents 78f8e06 + 79ee0b2 commit 1654bd1

17 files changed

+31
-32
lines changed

‎doc/changelog/1.21.5-changelog.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -22,7 +22,7 @@ A total of 11 pull requests were merged for this release.
2222
* `#20462 <https://github.com/numpy/numpy/pull/20462>`__: BUG: Fix float16 einsum fastpaths using wrong tempvar
2323
* `#20463 <https://github.com/numpy/numpy/pull/20463>`__: BUG, DIST: Print os error message when the executable not exist
2424
* `#20464 <https://github.com/numpy/numpy/pull/20464>`__: BLD: Verify the ability to compile C++ sources before initiating...
25-
* `#20465 <https://github.com/numpy/numpy/pull/20465>`__: BUG: Force ``npymath` ` to respect ``npy_longdouble``
25+
* `#20465 <https://github.com/numpy/numpy/pull/20465>`__: BUG: Force ``npymath`` to respect ``npy_longdouble``
2626
* `#20466 <https://github.com/numpy/numpy/pull/20466>`__: BUG: Fix failure to create aligned, empty structured dtype
2727
* `#20467 <https://github.com/numpy/numpy/pull/20467>`__: ENH: provide a convenience function to replace npy_load_module
2828
* `#20495 <https://github.com/numpy/numpy/pull/20495>`__: MAINT: update wheel to version that supports python3.10

‎doc/neps/nep-0021-advanced-indexing.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -123,7 +123,7 @@ with shape ``(1,)``, not a 2D sub-matrix with shape ``(1, 1)``.
123123
Mixed indexing seems so tricky that it is tempting to say that it never should
124124
be used. However, it is not easy to avoid, because NumPy implicitly adds full
125125
slices if there are fewer indices than the full dimensionality of the indexed
126-
array. This means that indexing a 2D array like `x[[0, 1]]`` is equivalent to
126+
array. This means that indexing a 2D array like ``x[[0, 1]]`` is equivalent to
127127
``x[[0, 1], :]``. These cases are not surprising, but they constrain the
128128
behavior of mixed indexing.
129129

@@ -236,7 +236,7 @@ be deduced:
236236
For the beginning, this probably means cases where ``arr[ind]`` and
237237
``arr.oindex[ind]`` return different results give deprecation warnings.
238238
This includes every use of vectorized indexing with multiple integer arrays.
239-
Due to the transposing behaviour, this means that``arr[0, :, index_arr]``
239+
Due to the transposing behaviour, this means that ``arr[0, :, index_arr]``
240240
will be deprecated, but ``arr[:, 0, index_arr]`` will not for the time being.
241241

242242
7. To ensure that existing subclasses of `ndarray` that override indexing
@@ -285,7 +285,7 @@ Open Questions
285285
Copying always "fixes" this possible inconsistency.
286286

287287
* The final state to morph plain indexing in is not fixed in this PEP.
288-
It is for example possible that `arr[index]`` will be equivalent to
288+
It is for example possible that ``arr[index]`` will be equivalent to
289289
``arr.oindex`` at some point in the future.
290290
Since such a change will take years, it seems unnecessary to make
291291
specific decisions at this time.

‎doc/neps/nep-0030-duck-array-protocol.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -102,14 +102,14 @@ a complete implementation would look like the following:
102102
The implementation above exemplifies the simplest case, but the overall idea
103103
is that libraries will implement a ``__duckarray__`` method that returns the
104104
original object, and an ``__array__`` method that either creates and returns an
105-
appropriate NumPy array, or raises a``TypeError`` to prevent unintentional use
105+
appropriate NumPy array, or raises a ``TypeError`` to prevent unintentional use
106106
as an object in a NumPy array (if ``np.asarray`` is called on an arbitrary
107107
object that does not implement ``__array__``, it will create a NumPy array
108108
scalar).
109109

110110
In case of existing libraries that don't already implement ``__array__`` but
111111
would like to use duck array typing, it is advised that they introduce
112-
both ``__array__`` and``__duckarray__`` methods.
112+
both ``__array__`` and ``__duckarray__`` methods.
113113

114114
Usage
115115
-----

‎doc/source/dev/internals.code-explanations.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -401,7 +401,7 @@ Iterators for the output arguments are then processed.
401401
Finally, the decision is made about how to execute the looping
402402
mechanism to ensure that all elements of the input arrays are combined
403403
to produce the output arrays of the correct type. The options for loop
404-
execution are one-loop (for :term`contiguous`, aligned, and correct data
404+
execution are one-loop (for :term:`contiguous`, aligned, and correct data
405405
type), strided-loop (for non-contiguous but still aligned and correct
406406
data type), and a buffered loop (for misaligned or incorrect data
407407
type situations). Depending on which execution method is called for,

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1618,7 +1618,7 @@ NumPy C-API and C complex
16181618
When you use the NumPy C-API, you will have access to complex real declarations
16191619
``npy_cdouble`` and ``npy_cfloat``, which are declared in terms of the C
16201620
standard types from ``complex.h``. Unfortunately, ``complex.h`` contains
1621-
`#define I ...`` (where the actual definition depends on the compiler), which
1621+
``#define I ...`` (where the actual definition depends on the compiler), which
16221622
means that any downstream user that does ``#include <numpy/arrayobject.h>``
16231623
could get ``I`` defined, and using something like declaring ``double I;`` in
16241624
their code will result in an obscure compiler error like

‎doc/source/reference/maskedarray.generic.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -66,7 +66,7 @@ attributes and methods are described in more details in the
6666

6767
.. try_examples::
6868

69-
The :mod:`numpy.ma` module can be used as an addition to :mod:`numpy`:
69+
The :mod:`numpy.ma` module can be used as an addition to :mod:`numpy`:
7070

7171
>>> import numpy as np
7272
>>> import numpy.ma as ma
@@ -521,7 +521,7 @@ Numerical operations
521521
--------------------
522522

523523
Numerical operations can be easily performed without worrying about missing
524-
values, dividing by zero, square roots of negative numbers, etc.::
524+
values, dividing by zero, square roots of negative numbers, etc.:
525525

526526
.. try_examples::
527527

‎doc/source/reference/simd/build-options.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -234,7 +234,7 @@ The need to align certain CPU features that are assured to be supported by
234234
successive generations of the same architecture, some cases:
235235

236236
- On ppc64le ``VSX(ISA 2.06)`` and ``VSX2(ISA 2.07)`` both imply one another since the
237-
first generation that supports little-endian mode is Power-8`(ISA 2.07)`
237+
first generation that supports little-endian mode is ``Power-8(ISA 2.07)``
238238
- On AArch64 ``NEON NEON_FP16 NEON_VFPV4 ASIMD`` implies each other since they are part of the
239239
hardware baseline.
240240

‎doc/source/release/1.11.0-notes.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -205,7 +205,7 @@ New Features
205205
- ``np.int16``, ``np.uint16``,
206206
- ``np.int32``, ``np.uint32``,
207207
- ``np.int64``, ``np.uint64``,
208-
- ``np.int_ ``, ``np.intp``
208+
- ``np.int_``, ``np.intp``
209209

210210
The specification is by precision rather than by C type. Hence, on some
211211
platforms ``np.int64`` may be a ``long`` instead of ``long long`` even if

‎doc/source/release/1.13.0-notes.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -136,7 +136,7 @@ implement ``__*slice__`` on the derived class, as ``__*item__`` will intercept
136136
these calls correctly.
137137

138138
Any code that did implement these will work exactly as before. Code that
139-
invokes``ndarray.__getslice__`` (e.g. through ``super(...).__getslice__``) will
139+
invokes ``ndarray.__getslice__`` (e.g. through ``super(...).__getslice__``) will
140140
now issue a DeprecationWarning - ``.__getitem__(slice(start, end))`` should be
141141
used instead.
142142

‎doc/source/release/1.14.0-notes.rst

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -409,8 +409,8 @@ This new default changes the float output relative to numpy 1.13. The old
409409
behavior can be obtained in 1.13 "legacy" printing mode, see compatibility
410410
notes above.
411411

412-
``hermitian`` option added to``np.linalg.matrix_rank``
413-
------------------------------------------------------
412+
``hermitian`` option added to ``np.linalg.matrix_rank``
413+
-------------------------------------------------------
414414
The new ``hermitian`` option allows choosing between standard SVD based matrix
415415
rank calculation and the more efficient eigenvalue based method for
416416
symmetric/hermitian matrices.

0 commit comments

Comments
 (0)
0