NumPy 1.25.0 Release Notes#
np.core.MachAris deprecated. It is private API. In names defined in
np.coreshould generally be considered private.
np.finfo.macharhave been removed.
!= warnings finalized#
!= operators on arrays now always:
raise errors that occur during comparisons such as when the arrays have incompatible shapes (
np.array([1, 2]) == np.array([1, 2, 3])).
return an array of all
Falsewhen values are fundamentally not comparable (e.g. have different dtypes). An example is
np.array(["a"]) == np.array().
This mimics the Python behavior of returning
when comparing incompatible types like
"a" == 1 and
"a" != 1.
For a long time these gave
When comparing datetimes and timedelta using
np.not_equalnumpy previously allowed the comparison with
casting="unsafe". This operation now fails. Forcing the output dtype using the
dtypekwarg can make the operation succeed, but we do not recommend it.
ulong_t were aliases for
and confusing (a remainder from of Python 2). This change may lead to the errors:
'long_t' is not a type identifier 'ulong_t' is not a type identifier
We recommend use of bit-sized types such as
cnp.int64_t or the use of
cnp.intp_t which is 32 bits on 32 bit systems and 64 bits on 64 bit
systems (this is most compatible with indexing).
long is desired, use plain
cnp.int_t is also
long (NumPy’s default integer). However,
is 32 bit on 64 bit windows and we may wish to adjust this even in NumPy.
(Please do not hesitate to contact NumPy developers if you are curious about this.)
Changed error message and type for bad
axes argument to
The error message and type when a wrong
axes value is passed to
ufunc(..., axes=[...])` has changed. The message is now more indicative of
the problem, and if the value is mismatched an
AxisError will be raised.
TypeError will still be raised for invalid input types.
NumPy now has an
NumPy now has a dedicated namespace making most exceptions and warnings available. All of these remain available in the main namespace, although some may be moved slowly in the future. The main reason for this is to increase discoverably and add future exceptions.
Fix power of complex zero#
np.power now returns a different result for
for complex numbers. Note that the value is only defined when
the real part of the exponent is larger than zero.
Previously, NaN was returned unless the imaginary part was strictly
zero. The return value is either
NumPy now has a new
DTypePromotionError which is used when two
dtypes cannot be promoted to a common one, for example:
raises this new exception.