Merge branch 'master' into npy-2.1

1 files changed, 72 insertions, 0 deletions

diff --git a/doc/release/1.17.0-notes.rst b/doc/release/1.17.0-notes.rst
index b18c0241c..c4c88fd20 100644
--- a/doc/release/1.17.0-notes.rst
+++ b/doc/release/1.17.0-notes.rst
@@ -66,6 +66,16 @@ zero::
    >>> np.zeros(10)//1
    array([0., 0., 0., 0., 0., 0., 0., 0., 0., 0.])
 
+``MaskedArray.mask`` now returns a view of the mask, not the mask itself
+------------------------------------------------------------------------
+Returning the mask itself was unsafe, as it could be reshaped in place which
+would violate expectations of the masked array code. It's behavior is now
+consistent with the ``.data`` attribute, which also returns a view.
+
+The underlying mask can still be accessed with ``._mask`` if it is needed.
+Tests that contain ``assert x.mask is not y.mask`` or similar will need to be
+updated.
+
 Do not lookup ``__buffer__`` attribute in `numpy.frombuffer`
 ------------------------------------------------------------
 Looking up ``__buffer__`` attribute in `numpy.frombuffer` was undocumented and
@@ -83,6 +93,17 @@ The functions ``np.load``, and ``np.lib.format.read_array`` take an
 `allow_pickle` keyword which now defaults to ``False`` in response to
 `CVE-2019-6446 <https://nvd.nist.gov/vuln/detail/CVE-2019-6446>`_.
 
+Potential changes to the random stream
+--------------------------------------
+Due to bugs in the application of log to random floating point numbers,
+the stream may change when sampling from ``np.random.beta``, ``np.random.binomial``,
+``np.random.laplace``, ``np.random.logistic``, ``np.random.logseries`` or
+``np.random.multinomial`` if a 0 is generated in the underlying MT19937 random stream.
+There is a 1 in :math:`10^{53}` chance of this occurring, and so the probability that
+the stream changes for any given seed is extremely small. If a 0 is encountered in the
+underlying generator, then the incorrect value produced (either ``np.inf``
+or ``np.nan``) is now dropped.
+
 C API changes
 =============
 
@@ -110,6 +131,9 @@ random data.  The algorithm is stable and requires O(n/2) working space.  For
 details of the algorithm, refer to
 `CPython listsort.txt <https://github.com/python/cpython/blob/3.7/Objects/listsort.txt>`_.
 
+In addition, for very small dtypes, radix sort is used instead of timsort. In
+general, we attempt to use the fastest possible implementation.
+
 ``np.unpackbits`` now accepts a ``count`` parameter
 ---------------------------------------------------
 ``count`` allows subsetting the number of bits that will be unpacked up-front,
@@ -154,6 +178,12 @@ This returns a (numerator, denominator) pair, which can be used to construct a
 A new format version of 3.0 has been introduced, which enables structured types
 with non-latin1 field names. This is used automatically when needed.
 
+`numpy.packbits` and `numpy.unpackbits` accept an ``order`` keyword
+-------------------------------------------------------------------
+The ``order`` keyword defaults to ``big``, and will order the **bits**
+accordingly. For ``'big'`` 3 will become ``[0, 0, 0, 0, 0, 0, 1, 1]``, and
+``[1, 1, 0, 0, 0, 0, 0, 0]`` for ``little``
+
 
 Improvements
 ============
@@ -176,6 +206,14 @@ maintains `O(N log N)` run time complexity instead of deteriorating towards
 `O(N*N)` for prime lengths. Also, accuracy for real-valued FFTs with near-prime
 lengths has improved and is on par with complex-valued FFTs.
 
+Performance improvements for integer sorts
+------------------------------------------
+
+``sort``, ``argsort``, ``ndarray.sort`` and ``ndarray.argsort`` now use radix
+sort as the default stable sort for integers and booleans. This is faster than
+the old default, mergesort, in the vast majority of cases.
+
+
 Further improvements to ``ctypes`` support in ``np.ctypeslib``
 --------------------------------------------------------------
 A new `numpy.ctypeslib.as_ctypes_type` function has been added, which can be
@@ -257,6 +295,15 @@ methods when called on object arrays, making them compatible with
 In general, this handles object arrays more gracefully, and avoids floating-
 point operations if exact arithmetic types are used.
 
+Support of object arrays in ``np.matmul``
+-----------------------------------------
+It is now possible to use ``np.matmul`` (or the ``@`` operator) with object arrays.
+For instance, it is now possible to do::
+
+    from fractions import Fraction
+    a = np.array([[Fraction(1, 2), Fraction(1, 3)], [Fraction(1, 3), Fraction(1, 2)]])
+    b = a @ a
+
 
 Changes
 =======
@@ -287,6 +334,31 @@ was accidental. The old behavior can be retained with
 ``structured_to_unstructured(arr[['a']]).squeeze(axis=-1)`` or far more simply,
 ``arr['a']``.
 
+``clip`` now uses a ufunc under the hood
+----------------------------------------
+This means that registering clip functions for custom dtypes in C via
+`descr->f->fastclip` is deprecated - they should use the ufunc registration
+mechanism instead, attaching to the ``np.core.umath.clip`` ufunc.
+
+It also means that ``clip`` accepts ``where`` and ``casting`` arguments,
+and can be override with ``__array_ufunc__``.
+
+A consequence of this change is that some behaviors of the old ``clip`` have
+been deprecated:
+
+* Passing ``nan`` to mean "do not clip" as one or both bounds. This didn't work
+  in all cases anyway, and can be better handled by passing infinities of the
+  appropriate sign.
+* Using "unsafe" casting by default when an ``out`` argument is passed. Using
+  ``casting="unsafe"`` explicitly will silence this warning.
+
+Additionally, there are some corner cases with behavior changes:
+
+* Padding ``max < min`` has changed to be more consistent across dtypes, but
+  should not be relied upon.
+* Scalar ``min`` and ``max`` take part in promotion rules like they do in all
+  other ufuncs.
+
 ``__array_interface__`` offset now works as documented
 ------------------------------------------------------
 The interface may use an ``offset`` value that was mistakenly ignored.