diff options
Diffstat (limited to 'doc/release')
42 files changed, 333 insertions, 0 deletions
diff --git a/doc/release/numpy2_changes/23089.change.rst b/doc/release/numpy2_changes/23089.change.rst new file mode 100644 index 000000000..fbd87e0aa --- /dev/null +++ b/doc/release/numpy2_changes/23089.change.rst @@ -0,0 +1,2 @@ +* ``np.gradient()`` now returns a tuple rather than list making the + return value immutable. diff --git a/doc/release/numpy2_changes/README.md b/doc/release/numpy2_changes/README.md new file mode 100644 index 000000000..fb59749a9 --- /dev/null +++ b/doc/release/numpy2_changes/README.md @@ -0,0 +1,4 @@ +Same as ``../upcoming_changes`` but for changes that currently +are opt-in behind ``NPY_NUMPY_2_BEHAVIOR=1``. + +This is to get a start on release notes for such changes. diff --git a/doc/release/upcoming_changes/10615.deprecation.rst b/doc/release/upcoming_changes/10615.deprecation.rst new file mode 100644 index 000000000..7fa948ea8 --- /dev/null +++ b/doc/release/upcoming_changes/10615.deprecation.rst @@ -0,0 +1,14 @@ +Only ndim-0 arrays are treated as scalars +----------------------------------------- +NumPy used to treat all arrays of size 1 (e.g., ``np.array([3.14])``) as scalars. +In the future, this will be limited to arrays of ndim 0 (e.g., ``np.array(3.14)``). +The following expressions will report a deprecation warning: + +.. code-block:: python + + a = np.array([3.14]) + float(a) # better: a[0] to get the numpy.float or a.item() + + b = np.array([[3.14]]) + c = numpy.random.rand(10) + c[0] = b # better: c[0] = b[0, 0] diff --git a/doc/release/upcoming_changes/18053.new_feature.rst b/doc/release/upcoming_changes/18053.new_feature.rst new file mode 100644 index 000000000..fea04f79a --- /dev/null +++ b/doc/release/upcoming_changes/18053.new_feature.rst @@ -0,0 +1,4 @@ +``np.einsum`` now accepts arrays with ``object`` dtype +------------------------------------------------------ +The code path will call python operators on object dtype arrays, much +like ``np.dot`` and ``np.matmul``. diff --git a/doc/release/upcoming_changes/21120.new_feature.rst b/doc/release/upcoming_changes/21120.new_feature.rst new file mode 100644 index 000000000..7d4dbf743 --- /dev/null +++ b/doc/release/upcoming_changes/21120.new_feature.rst @@ -0,0 +1,21 @@ +Add support for inplace matrix multiplication +---------------------------------------------- +It is now possible to perform inplace matrix multiplication +via the ``@=`` operator. + +.. code-block:: python + + >>> import numpy as np + + >>> a = np.arange(6).reshape(3, 2) + >>> print(a) + [[0 1] + [2 3] + [4 5]] + + >>> b = np.ones((2, 2), dtype=int) + >>> a @= b + >>> print(a) + [[1 1] + [5 5] + [9 9]] diff --git a/doc/release/upcoming_changes/22315.performance.rst b/doc/release/upcoming_changes/22315.performance.rst new file mode 100644 index 000000000..a2f623e5a --- /dev/null +++ b/doc/release/upcoming_changes/22315.performance.rst @@ -0,0 +1,7 @@ +Faster ``np.sort`` on AVX-512 enabled processors +------------------------------------------------ +Quicksort for 16-bit and 64-bit dtypes gain up to 15x and 9x speed up on +processors that support AVX-512 instruction set. + +Thanks to `Intel corporation <https://open.intel.com/>`_ for sponsoring this +work. diff --git a/doc/release/upcoming_changes/22539.change.rst b/doc/release/upcoming_changes/22539.change.rst new file mode 100644 index 000000000..9df62be30 --- /dev/null +++ b/doc/release/upcoming_changes/22539.change.rst @@ -0,0 +1,19 @@ +``np.r_[]`` and ``np.c_[]`` with certain scalar values +------------------------------------------------------ +In rare cases, using mainly ``np.r_`` with scalars can lead to different +results. The main potential changes are highlighted by the following:: + + >>> np.r_[np.arange(5, dtype=np.uint8), -1].dtype + int16 # rather than the default integer (int64 or int32) + >>> np.r_[np.arange(5, dtype=np.int8), 255] + array([ 0, 1, 2, 3, 4, 255], dtype=int16) + +Where the second example returned:: + + array([ 0, 1, 2, 3, 4, -1], dtype=int8) + +The first one is due to a signed integer scalar with an unsigned integer +array, while the second is due to ``255`` not fitting into ``int8`` and +NumPy currently inspecting values to make this work. +(Note that the second example is expected to change in the future due to +:ref:`NEP 50 <NEP50>`; it will then raise an error.) diff --git a/doc/release/upcoming_changes/22539.deprecation.rst b/doc/release/upcoming_changes/22539.deprecation.rst new file mode 100644 index 000000000..a30434b7e --- /dev/null +++ b/doc/release/upcoming_changes/22539.deprecation.rst @@ -0,0 +1,29 @@ +``np.find_common_type`` is deprecated +------------------------------------- +`numpy.find_common_type` is now deprecated and its use should be replaced +with either `numpy.result_type` or `numpy.promote_types`. +Most users leave the second ``scalar_types`` argument to ``find_common_type`` +as ``[]`` in which case ``np.result_type`` and ``np.promote_types`` are both +faster and more robust. +When not using ``scalar_types`` the main difference is that the replacement +intentionally converts non-native byte-order to native byte order. +Further, ``find_common_type`` returns ``object`` dtype rather than failing +promotion. This leads to differences when the inputs are not all numeric. +Importantly, this also happens for e.g. timedelta/datetime for which NumPy +promotion rules are currently sometimes surprising. + +When the ``scalar_types`` argument is not ``[]`` things are more complicated. +In most cases, using ``np.result_type`` and passing the Python values +``0``, ``0.0``, or ``0j`` has the same result as using ``int``, ``float``, +or ``complex`` in `scalar_types`. + +When ``scalar_types`` is constructed, ``np.result_type`` is the +correct replacement and it may be passed scalar values like ``np.float32(0.0)``. +Passing values other than 0, may lead to value-inspecting behavior +(which ``np.find_common_type`` never used and NEP 50 may change in the future). +The main possible change in behavior in this case, is when the array types +are signed integers and scalar types are unsigned. + +If you are unsure about how to replace a use of ``scalar_types`` or when +non-numeric dtypes are likely, please do not hesitate to open a NumPy issue +to ask for help. diff --git a/doc/release/upcoming_changes/22769.improvement.rst b/doc/release/upcoming_changes/22769.improvement.rst new file mode 100644 index 000000000..3566648ac --- /dev/null +++ b/doc/release/upcoming_changes/22769.improvement.rst @@ -0,0 +1,5 @@ +`np.show_config` uses information from Meson +-------------------------------------------- +Build and system information now contains information from Meson. +`np.show_config` now has a new optional parameter ``mode`` to help +customize the output. diff --git a/doc/release/upcoming_changes/22776.improvement.rst b/doc/release/upcoming_changes/22776.improvement.rst new file mode 100644 index 000000000..669fcff16 --- /dev/null +++ b/doc/release/upcoming_changes/22776.improvement.rst @@ -0,0 +1,6 @@ +Fix ``np.ma.diff`` not preserving the mask when called with arguments prepend/append. +------------------------------------------------------------------------------------- +Calling ``np.ma.diff`` with arguments prepend and/or append now returns a +``MaskedArray`` with the input mask preserved. + +Previously, a ``MaskedArray`` without the mask was returned.
\ No newline at end of file diff --git a/doc/release/upcoming_changes/22863.new_feature.rst b/doc/release/upcoming_changes/22863.new_feature.rst new file mode 100644 index 000000000..3f45ed834 --- /dev/null +++ b/doc/release/upcoming_changes/22863.new_feature.rst @@ -0,0 +1,4 @@ +String functions in np.char are compatible with NEP 42 custom dtypes +-------------------------------------------------------------------- +Custom dtypes that represent unicode strings or byte strings can now be +passed to the string functions in np.char. diff --git a/doc/release/upcoming_changes/22963.new_feature.rst b/doc/release/upcoming_changes/22963.new_feature.rst new file mode 100644 index 000000000..88ec3f641 --- /dev/null +++ b/doc/release/upcoming_changes/22963.new_feature.rst @@ -0,0 +1,7 @@ +String dtype instances can be created from the string abstract dtype classes +---------------------------------------------------------------------------- +It is now possible to create a string dtype instance with a size without +using the string name of the dtype. For example, ``type(np.dtype('U'))(8)`` +will create a dtype that is equivalent to ``np.dtype('U8')``. This feature +is most useful when writing generic code dealing with string dtype +classes. diff --git a/doc/release/upcoming_changes/22982.new_feature.rst b/doc/release/upcoming_changes/22982.new_feature.rst new file mode 100644 index 000000000..c98f2791c --- /dev/null +++ b/doc/release/upcoming_changes/22982.new_feature.rst @@ -0,0 +1,13 @@ +Fujitsu C/C++ compiler is now supported +---------------------------------------------- +Support for Fujitsu compiler has been added. +To build with Fujitsu compiler, run: + + python setup.py build -c fujitsu + + +SSL2 is now supported +----------------------------------- +Support for SSL2 has been added. SSL2 is a library that provides OpenBLAS compatible GEMM functions. +To enable SSL2, it need to edit site.cfg and build with Fujitsu compiler. +See site.cfg.example. diff --git a/doc/release/upcoming_changes/22997.improvement.rst b/doc/release/upcoming_changes/22997.improvement.rst new file mode 100644 index 000000000..156c9dece --- /dev/null +++ b/doc/release/upcoming_changes/22997.improvement.rst @@ -0,0 +1,5 @@ +Corrected error handling for NumPy C-API in Cython +-------------------------------------------------- +Many NumPy C functions defined for use in Cython were lacking the +correct error indicator like ``except -1`` or ``except *``. +These have now been added. diff --git a/doc/release/upcoming_changes/22998.expired.rst b/doc/release/upcoming_changes/22998.expired.rst new file mode 100644 index 000000000..a4399b639 --- /dev/null +++ b/doc/release/upcoming_changes/22998.expired.rst @@ -0,0 +1,2 @@ +* ``+arr`` will now raise an error when the dtype is not + numeric (and positive is undefined). diff --git a/doc/release/upcoming_changes/23011.deprecation.rst b/doc/release/upcoming_changes/23011.deprecation.rst new file mode 100644 index 000000000..72168ff87 --- /dev/null +++ b/doc/release/upcoming_changes/23011.deprecation.rst @@ -0,0 +1 @@ +* ``np.finfo(None)`` is deprecated. diff --git a/doc/release/upcoming_changes/23019.expired.rst b/doc/release/upcoming_changes/23019.expired.rst new file mode 100644 index 000000000..0879c2658 --- /dev/null +++ b/doc/release/upcoming_changes/23019.expired.rst @@ -0,0 +1,2 @@ +* A sequence must now be passed into the stacking family of functions + (``stack``, ``vstack``, ``hstack``, ``dstack`` and ``column_stack``). diff --git a/doc/release/upcoming_changes/23020.change.rst b/doc/release/upcoming_changes/23020.change.rst new file mode 100644 index 000000000..b4198fcba --- /dev/null +++ b/doc/release/upcoming_changes/23020.change.rst @@ -0,0 +1,9 @@ +Most NumPy functions are wrapped into a C-callable +-------------------------------------------------- +To speed up the ``__array_function__`` dispatching, most NumPy functions +are now wrapped into C-callables and are not proper Python functions or +C methods. +They still look and feel the same as before (like a Python function), and this +should only improve performance and user experience (cleaner tracebacks). +However, please inform the NumPy developers if this change confuses your +program for some reason. diff --git a/doc/release/upcoming_changes/23020.performance.rst b/doc/release/upcoming_changes/23020.performance.rst new file mode 100644 index 000000000..db9fcbf3c --- /dev/null +++ b/doc/release/upcoming_changes/23020.performance.rst @@ -0,0 +1,5 @@ +``__array_function__`` machinery is now much faster +--------------------------------------------------- +The overhead of the majority of functions in NumPy is now smaller +especially when keyword arguments are used. This change significantly +speeds up many simple function calls. diff --git a/doc/release/upcoming_changes/23041.expired.rst b/doc/release/upcoming_changes/23041.expired.rst new file mode 100644 index 000000000..9049ea70f --- /dev/null +++ b/doc/release/upcoming_changes/23041.expired.rst @@ -0,0 +1,27 @@ +Nose support has been removed +----------------------------- +NumPy switched to using pytest in 2018 and nose has been unmaintained for many +years. We have kept NumPy's nose support to avoid breaking downstream projects +who might have been using it and not yet switched to pytest or some other +testing framework. With the arrival of Python 3.12, unpatched nose will raise +an error. It is time to move on. + +Decorators removed +^^^^^^^^^^^^^^^^^^ +- raises +- slow +- setastest +- skipif +- knownfailif +- deprecated +- parametrize +- _needs_refcount + +These are not to be confused with pytest versions with similar names, e.g., +pytest.mark.slow, pytest.mark.skipif, pytest.mark.parametrize. + +Functions removed +^^^^^^^^^^^^^^^^^ +- Tester +- import_nose +- run_module_suite diff --git a/doc/release/upcoming_changes/23060.expired.rst b/doc/release/upcoming_changes/23060.expired.rst new file mode 100644 index 000000000..f80ba6fd0 --- /dev/null +++ b/doc/release/upcoming_changes/23060.expired.rst @@ -0,0 +1,5 @@ +The ``numpy.testing.utils`` shim has been removed. +-------------------------------------------------- +Importing from the ``numpy.testing.utils`` shim has been deprecated since 2019, +the shim has now been removed. All imports should be made directly from +``numpy.testing``. diff --git a/doc/release/upcoming_changes/23105.compatibility.rst b/doc/release/upcoming_changes/23105.compatibility.rst new file mode 100644 index 000000000..8a0b677e5 --- /dev/null +++ b/doc/release/upcoming_changes/23105.compatibility.rst @@ -0,0 +1,5 @@ +* When loading data from a file handle using ``np.load``, + if the handle is at the end of file, as can happen when reading + multiple arrays by calling ``np.load`` repeatedly, numpy previously + raised ``ValueError`` if ``allow_pickle=False``, and ``OSError`` if + ``allow_pickle=True``. Now it raises ``EOFError`` instead, in both cases. diff --git a/doc/release/upcoming_changes/23113.improvement.rst b/doc/release/upcoming_changes/23113.improvement.rst new file mode 100644 index 000000000..299b8f762 --- /dev/null +++ b/doc/release/upcoming_changes/23113.improvement.rst @@ -0,0 +1,3 @@ +- The ``NDArrayOperatorsMixin`` class now specifies that it contains no + ``__slots__`` ensureing that subclasses can now make use of this feature in + Python. diff --git a/doc/release/upcoming_changes/23136.performance.rst b/doc/release/upcoming_changes/23136.performance.rst new file mode 100644 index 000000000..1096f8bd1 --- /dev/null +++ b/doc/release/upcoming_changes/23136.performance.rst @@ -0,0 +1,18 @@ +``ufunc.at`` can be much faster +------------------------------- +Generic ``ufunc.at`` can be up to 9x faster. The conditions for this speedup: + +- operands are aligned +- no casting + +If ufuncs with appropriate indexed loops on 1d arguments with the above +conditions, ``ufunc.at`` can be up to 60x faster (an additional 7x speedup). +Appropriate indexed loops have been added to ``add``, ``subtract``, +``multiply``, ``floor_divide``, ``maximum``, ``minimum``, ``fmax``, and +``fmin``. + +The internal logic is similar to the logic used for regular ufuncs, which also +have fast paths. + +Thanks to the `D. E. Shaw group <https://deshaw.com/>`_ for sponsoring this +work. diff --git a/doc/release/upcoming_changes/23195.improvement.rst b/doc/release/upcoming_changes/23195.improvement.rst new file mode 100644 index 000000000..38b33e849 --- /dev/null +++ b/doc/release/upcoming_changes/23195.improvement.rst @@ -0,0 +1,20 @@ +Ability to directly spawn random number generators +-------------------------------------------------- +`numpy.random.Generator.spawn` now allows to directly spawn new +independent child generators via the `numpy.random.SeedSequence.spawn` +mechanism. +`numpy.random.BitGenerator.spawn` does the same for the underlying +bit generator. + +Additionally, `numpy.random.BitGenerator.seed_seq` now gives direct +access to the seed sequence used for initializing the bit generator. +This allows for example:: + + seed = 0x2e09b90939db40c400f8f22dae617151 + rng = np.random.default_rng(seed) + child_rng1, child_rng2 = rng.spawn(2) + + # safely use rng, child_rng1, and child_rng2 + +Previously, this was hard to do without passing the ``SeedSequence`` +explicitly. Please see `numpy.random.SeedSequence` for more information. diff --git a/doc/release/upcoming_changes/23229.compatibility.rst b/doc/release/upcoming_changes/23229.compatibility.rst new file mode 100644 index 000000000..284cc06ab --- /dev/null +++ b/doc/release/upcoming_changes/23229.compatibility.rst @@ -0,0 +1,3 @@ +- The ``busday_count`` method now correctly handles cases where the ``begindates`` is later in time + than the ``enddates``. Previously, the ``enddates`` was included, even though the documentation states + it is always excluded. diff --git a/doc/release/upcoming_changes/23240.compatibility.rst b/doc/release/upcoming_changes/23240.compatibility.rst new file mode 100644 index 000000000..28536a020 --- /dev/null +++ b/doc/release/upcoming_changes/23240.compatibility.rst @@ -0,0 +1,10 @@ +Array-likes that define ``__array_ufunc__`` can now override ufuncs if used as ``where`` +---------------------------------------------------------------------------------------- +If the ``where`` keyword argument of a :class:`numpy.ufunc` is a subclass of +:class:`numpy.ndarray` or is a duck type that defines +:func:`numpy.class.__array_ufunc__` it can override the behavior of the ufunc +using the same mechanism as the input and output arguments. +Note that for this to work properly, the ``where.__array_ufunc__`` +implementation will have to unwrap the ``where`` argument to pass it into the +default implementation of the ``ufunc`` or, for :class:`numpy.ndarray` +subclasses before using ``super().__array_ufunc__``.
\ No newline at end of file diff --git a/doc/release/upcoming_changes/23275.improvement.rst b/doc/release/upcoming_changes/23275.improvement.rst new file mode 100644 index 000000000..14ed5d9ad --- /dev/null +++ b/doc/release/upcoming_changes/23275.improvement.rst @@ -0,0 +1,4 @@ +``numpy.logspace`` now supports a non-scalar ``base`` argument +-------------------------------------------------------------- +The ``base`` argument of ``numpy.logspace`` can now be array-like if it's +broadcastable against the ``start`` and ``stop`` arguments.
\ No newline at end of file diff --git a/doc/release/upcoming_changes/23302.deprecation.rst b/doc/release/upcoming_changes/23302.deprecation.rst new file mode 100644 index 000000000..9e36d658c --- /dev/null +++ b/doc/release/upcoming_changes/23302.deprecation.rst @@ -0,0 +1 @@ +* ``np.round_`` is deprecated. Use `np.round` instead. diff --git a/doc/release/upcoming_changes/23314.deprecation.rst b/doc/release/upcoming_changes/23314.deprecation.rst new file mode 100644 index 000000000..8bed1aef8 --- /dev/null +++ b/doc/release/upcoming_changes/23314.deprecation.rst @@ -0,0 +1,4 @@ +* ``np.product`` is deprecated. Use `np.prod` instead. +* ``np.cumproduct`` is deprecated. Use `np.cumprod` instead. +* ``np.sometrue`` is deprecated. Use `np.any` instead. +* ``np.alltrue`` is deprecated. Use `np.all` instead. diff --git a/doc/release/upcoming_changes/23322.improvement.rst b/doc/release/upcoming_changes/23322.improvement.rst new file mode 100644 index 000000000..ce5ab8cf5 --- /dev/null +++ b/doc/release/upcoming_changes/23322.improvement.rst @@ -0,0 +1,4 @@ +`np.ma.dot()` now supports for non-2d arrays +-------------------------------------------- +Previously `np.ma.dot()` only worked if `a` and `b` were both 2d. +Now it works for non-2d arrays as well as `np.dot()`. diff --git a/doc/release/upcoming_changes/23357.improvement.rst b/doc/release/upcoming_changes/23357.improvement.rst new file mode 100644 index 000000000..3b474146b --- /dev/null +++ b/doc/release/upcoming_changes/23357.improvement.rst @@ -0,0 +1,9 @@ +Explicitly show keys of .npz file in repr +----------------------------------------- +``NpzFile`` shows keys of loaded .npz file when printed. + +.. code-block:: python + + >>> npzfile = np.load('arr.npz') + >>> npzfile + NpzFile 'arr.npz' with keys arr_0, arr_1, arr_2, arr_3, arr_4... diff --git a/doc/release/upcoming_changes/23358.improvement.rst b/doc/release/upcoming_changes/23358.improvement.rst new file mode 100644 index 000000000..a8a0e56ef --- /dev/null +++ b/doc/release/upcoming_changes/23358.improvement.rst @@ -0,0 +1,5 @@ +NumPy now exposes DType classes in ``np.dtypes`` +------------------------------------------------ +The new `numpy.dtypes` module now exposes DType classes and +will contain future dtype related functionality. +Most users should have no need to use these classes directly. diff --git a/doc/release/upcoming_changes/23376.expired.rst b/doc/release/upcoming_changes/23376.expired.rst new file mode 100644 index 000000000..e289b087c --- /dev/null +++ b/doc/release/upcoming_changes/23376.expired.rst @@ -0,0 +1,9 @@ +Environment variable to disable dispatching removed +--------------------------------------------------- +Support for the ``NUMPY_EXPERIMENTAL_ARRAY_FUNCTION`` environment variable has +been removed. This variable disabled dispatching with ``__array_function__``. + +Support for ``y=`` as an alias of ``out=`` removed +-------------------------------------------------- +The ``fix``, ``isposinf`` and ``isneginf`` functions allowed using ``y=`` as a +(deprecated) alias for ``out=``. This is no longer supported. diff --git a/doc/release/upcoming_changes/23403.expired.rst b/doc/release/upcoming_changes/23403.expired.rst new file mode 100644 index 000000000..b099eb4e9 --- /dev/null +++ b/doc/release/upcoming_changes/23403.expired.rst @@ -0,0 +1,4 @@ +* ``np.clip`` now defaults to same-kind casting. Falling back to + unsafe casting was deprecated in NumPy 1.17. +* ``np.clip`` will now propagate ``np.nan`` values passed as ``min`` or ``max``. + Previously, a scalar NaN was usually ignored. This was deprecated in NumPy 1.17. diff --git a/doc/release/upcoming_changes/23480.expired.rst b/doc/release/upcoming_changes/23480.expired.rst new file mode 100644 index 000000000..164677b98 --- /dev/null +++ b/doc/release/upcoming_changes/23480.expired.rst @@ -0,0 +1 @@ +* The ``np.dual`` submodule has been removed. diff --git a/doc/release/upcoming_changes/23528.compatibility.rst b/doc/release/upcoming_changes/23528.compatibility.rst new file mode 100644 index 000000000..439fb6a27 --- /dev/null +++ b/doc/release/upcoming_changes/23528.compatibility.rst @@ -0,0 +1,16 @@ +By default, the exported NumPy C API is now compatible with NumPy 1.19 +---------------------------------------------------------------------- +Starting with NumPy 1.25 when including NumPy headers, NumPy now +defaults to exposing a backwards compatible API. +This means that by default binaries such as wheels build against +NumPy 1.25 will also work with NumPy 1.16 because it has the same API version +as NumPy 1.19 which is the oldest NumPy version compatible with Python 3.9. + +You can customize this behavior using:: + + #define NPY_TARGET_VERSION NPY_1_22_API_VERSION + +or the equivalent ``-D`` option to the compiler. For more details +please see `for-downstream-package-authors`_. +A change should only be required in rare cases when a package relies on newly +added C-API. diff --git a/doc/release/upcoming_changes/23601.change.rst b/doc/release/upcoming_changes/23601.change.rst new file mode 100644 index 000000000..e09bd50fe --- /dev/null +++ b/doc/release/upcoming_changes/23601.change.rst @@ -0,0 +1,6 @@ +C++ standard library usage +-------------------------- + +NumPy builds now depend on the C++ standard library, because +the ``numpy.core._multiarray_umath`` extension is linked with +the C++ linker. diff --git a/doc/release/upcoming_changes/23660.expired.rst b/doc/release/upcoming_changes/23660.expired.rst new file mode 100644 index 000000000..615367350 --- /dev/null +++ b/doc/release/upcoming_changes/23660.expired.rst @@ -0,0 +1,2 @@ +* NumPy now always ignores sequence behavior for an array-like (defining + one of the array protocols). (Deprecation started NumPy 1.20) diff --git a/doc/release/upcoming_changes/23661.performance.rst b/doc/release/upcoming_changes/23661.performance.rst new file mode 100644 index 000000000..e3e55f3d5 --- /dev/null +++ b/doc/release/upcoming_changes/23661.performance.rst @@ -0,0 +1,4 @@ +Faster membership test on ``NpzFile`` +------------------------------------- +Membership test on ``NpzFile`` will no longer +decompress the archive if it is successful. diff --git a/doc/release/upcoming_changes/23666.expired.rst b/doc/release/upcoming_changes/23666.expired.rst new file mode 100644 index 000000000..eb51c91f3 --- /dev/null +++ b/doc/release/upcoming_changes/23666.expired.rst @@ -0,0 +1,5 @@ +* The niche ``FutureWarning`` when casting to a subarray dtype in ``astype`` + or the array creation functions such as ``asarray`` is now finalized. + The behavior is now always the same as if the subarray dtype was + wrapped into a single field (which was the workaround, previously). + (FutureWarning since NumPy 1.20) diff --git a/doc/release/upcoming_changes/23713.improvement.rst b/doc/release/upcoming_changes/23713.improvement.rst new file mode 100644 index 000000000..15a4f412b --- /dev/null +++ b/doc/release/upcoming_changes/23713.improvement.rst @@ -0,0 +1,9 @@ +Signed and unsigned integers always compare correctly +----------------------------------------------------- +When ``uint64`` and ``int64`` are mixed in NumPy, NumPy typically +promotes both to ``float64``. This behavior may be argued about +but is confusing for comparisons ``==``, ``<=``, since the results +returned can be incorrect but the conversion is hidden since the +result is a boolean. +NumPy will now return the correct results for these by avoiding +the cast to float. |