diff options
| author | Matti Picus <matti.picus@gmail.com> | 2020-08-23 18:44:03 +0300 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-08-23 18:44:03 +0300 |
| commit | 551773f27ccc955ce24d15eae84eed924250c573 (patch) | |
| tree | bdcdb1625c291b4ecf79e0abc34ab91f3a493ace | |
| parent | 67c68b88e4120a84ec516725e322265446fc50e6 (diff) | |
| parent | 00fa130e704951757a1d76d928e741b77da0b4a7 (diff) | |
| download | numpy-551773f27ccc955ce24d15eae84eed924250c573.tar.gz | |
Merge pull request #17142 from WarrenWeckesser/copy-edit-nep-42
DOC: NEP-42: Fix a few typos.
| -rw-r--r-- | doc/neps/nep-0042-new-dtypes.rst | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/neps/nep-0042-new-dtypes.rst b/doc/neps/nep-0042-new-dtypes.rst index 1f476114f..b37555892 100644 --- a/doc/neps/nep-0042-new-dtypes.rst +++ b/doc/neps/nep-0042-new-dtypes.rst @@ -267,7 +267,7 @@ information is currently provided and will be defined on the class: deprecated. This may be relaxed if a use-case arises. Additionally, existing methods (and C-side fields) will be provided. -However, the fields ``kind`` and and ``char`` will be set to ``\0`` +However, the fields ``kind`` and ``char`` will be set to ``\0`` (NULL character) on the C-side. While discouraged, except for NumPy builtin types, ``kind`` both will return the ``__qualname__`` of the object to ensure uniqueness for all DTypes. @@ -307,7 +307,7 @@ is the ``np.datetime64`` scalar. A potential DType such as ``Categorical`` will not be required to have a clear type associated with it. Instead, the ``type`` may be ``object`` and the -categoircal's values are arbitrary objects. +categorical's values are arbitrary objects. Unlike with well-defined scalars, this ``type`` cannot not be used for the dtype discovery necessary for coercion (compare section `DType Discovery during Array Coercion`_). @@ -659,7 +659,7 @@ should be "minutes". Common DType Operations ^^^^^^^^^^^^^^^^^^^^^^^ -Numpy currently provides functions like ``np.result_type`` and +NumPy currently provides functions like ``np.result_type`` and ``np.promote_types`` for determining common types. These differ in that ``np.result_type`` can take arrays and scalars as input and implements value based promotion [1]_. @@ -972,7 +972,7 @@ In general we could implement certain casts, such as ``int8`` to ``int24`` even if the user only provides an ``int16 -> int24`` cast. This proposal currently does not provide this functionality. However, it could be extended in the future to either find such casts dynamically, -or at least allow ``adjust_descriptors`` to return arbitray ``dtypes``. +or at least allow ``adjust_descriptors`` to return arbitrary ``dtypes``. If ``CastingImpl[Int8, Int24].adjust_descriptors((int8, int24))`` returns ``(int16, int24)``, the actual casting process could be extended to include the ``int8 -> int16`` cast. Unlike the above example, which is limited |