diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/neps/nep-0042-new-dtypes.rst | 9 | ||||
| -rw-r--r-- | doc/neps/nep-0043-extensible-ufuncs.rst | 10 | ||||
| -rw-r--r-- | doc/source/release/1.21.0-notes.rst | 33 | ||||
| -rw-r--r-- | doc/source/user/building.rst | 4 |
4 files changed, 14 insertions, 42 deletions
diff --git a/doc/neps/nep-0042-new-dtypes.rst b/doc/neps/nep-0042-new-dtypes.rst index 1738bd1ab..bb85f1d10 100644 --- a/doc/neps/nep-0042-new-dtypes.rst +++ b/doc/neps/nep-0042-new-dtypes.rst @@ -1334,7 +1334,7 @@ Although verbose, the API will mimic the one for creating a new DType: typedef struct{ int flags; /* e.g. whether the cast requires the API */ int nin, nout; /* Number of Input and outputs (always 1) */ - NPY_CASTING casting; /* The default casting level */ + NPY_CASTING casting; /* The "minimal casting level" */ PyArray_DTypeMeta *dtypes; /* input and output DType class */ /* NULL terminated slots defining the methods */ PyType_Slot *slots; @@ -1342,7 +1342,7 @@ Although verbose, the API will mimic the one for creating a new DType: The focus differs between casting and general ufuncs. For example, for casts ``nin == nout == 1`` is always correct, while for ufuncs ``casting`` is -expected to be usually `"safe"`. +expected to be usually `"no"`. **Notes:** We may initially allow users to define only a single loop. Internally NumPy optimizes far more, and this should be made public @@ -1357,6 +1357,11 @@ incrementally in one of two ways: * Or, more likely, expose the ``get_loop`` function which is passed additional information, such as the fixed strides (similar to our internal API). +* The casting level denotes the minimal guaranteed casting level and can be + ``-1`` if the cast may be impossible. For most non-parametric casts, this + value will be the casting level. NumPy may skip the ``resolve_descriptors`` + call for ``np.can_cast()`` when the result is ``True`` based on this level. + The example does not yet include setup and error handling. Since these are similar to the UFunc machinery, they will be defined in :ref:`NEP 43 <NEP43>` and then incorporated identically into casting. diff --git a/doc/neps/nep-0043-extensible-ufuncs.rst b/doc/neps/nep-0043-extensible-ufuncs.rst index 3c6407728..cd73108e4 100644 --- a/doc/neps/nep-0043-extensible-ufuncs.rst +++ b/doc/neps/nep-0043-extensible-ufuncs.rst @@ -262,8 +262,8 @@ to define string equality, will be added to a ufunc. if given_descrs[2] is None: out_descr = DTypes[2]() - # The operation is always "safe" casting (most ufuncs are) - return (given_descrs[0], given_descrs[1], out_descr), "safe" + # The operation is always "no" casting (most ufuncs are) + return (given_descrs[0], given_descrs[1], out_descr), "no" def strided_loop(context, dimensions, data, strides, innerloop_data): """The 1-D strided loop, similar to those used in current ufuncs""" @@ -434,7 +434,7 @@ a new ``ArrayMethod`` object: # Casting safety information (almost always "safe", necessary to # unify casting and universal functions) - casting: Casting = "safe" + casting: Casting = "no" # More general flags: flags: int @@ -751,7 +751,7 @@ This step is required to allocate output arrays and has to happen before casting can be prepared. While the returned casting-safety (``NPY_CASTING``) will almost always be -"safe" for universal functions, including it has two big advantages: +"no" for universal functions, including it has two big advantages: * ``-1`` indicates that an error occurred. If a Python error is set, it will be raised. If no Python error is set this will be considered an "impossible" @@ -767,7 +767,7 @@ While the returned casting-safety (``NPY_CASTING``) will almost always be perspective. Currently, this would use ``int64 + int64 -> int64`` and then cast to ``int32``. An implementation that skips the cast would have to signal that it effectively includes the "same-kind" cast and is - thus not considered "safe". + thus not considered "no". ``get_loop`` method diff --git a/doc/source/release/1.21.0-notes.rst b/doc/source/release/1.21.0-notes.rst index ac65b8fd0..c0d283b72 100644 --- a/doc/source/release/1.21.0-notes.rst +++ b/doc/source/release/1.21.0-notes.rst @@ -82,39 +82,6 @@ The methods in question are: Future Changes ============== -Promotion of strings with numbers and bools is deprecated ---------------------------------------------------------- -Any promotion of numbers and strings is deprecated and will -give a ``FutureWarning`` the main affected functionalities -are: - -* `numpy.promote_types` and `numpy.result_type` which will raise - an error in this case in the future. -* `numpy.concatenate` will raise an error when concatenating a string - and numeric array. You can use ``dtype="S"`` to explicitly request - a string result. -* `numpy.array` and related functions will start returning ``object`` - arrays because these functions use ``object`` as a fallback when - no common dtype can be found. However, it may happen that future - releases of NumPy will generally error in these cases. - -This will mainly affect code such as:: - - np.asarray(['string', 0]) - -and:: - - np.concatenate((['string'], [0])) - -in both cases adding ``dtype="U"`` or ``dtype="S"`` will give the -previous (string) result, while ``dtype=object`` will ensure an array with -object dtype is returned. - -Comparisons, universal functions, and casting are not affected by this. - -(`gh-18116 <https://github.com/numpy/numpy/pull/18116>`__) - - Expired deprecations ==================== diff --git a/doc/source/user/building.rst b/doc/source/user/building.rst index 52d7330bf..1d1286b42 100644 --- a/doc/source/user/building.rst +++ b/doc/source/user/building.rst @@ -24,8 +24,8 @@ Building NumPy requires the following software installed: 2) Compilers To build any extension modules for Python, you'll need a C compiler. - Various NumPy modules use FORTRAN 77 libraries, so you'll also need a - FORTRAN 77 compiler installed. + While a FORTRAN 77 compiler is not necessary for building NumPy, it is needed to run + the ``numpy.f2py`` tests. These tests are skipped if the compiler is not auto-detected. Note that NumPy is developed mainly using GNU compilers and tested on MSVC and Clang compilers. Compilers from other vendors such as Intel, |