# NumPy 1.25.0 Release Notes#

## Deprecations#

`np.core.MachAr`

is deprecated. It is private API. In names defined in`np.core`

should generally be considered private.(gh-22638)

## Expired deprecations#

`np.core.machar`

and`np.finfo.machar`

have been removed.(gh-22638)

`==`

and `!=`

warnings finalized#

The `==`

and `!=`

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

`True`

or all`False`

when values are fundamentally not comparable (e.g. have different dtypes). An example is`np.array(["a"]) == np.array([1])`

.

This mimics the Python behavior of returning `False`

and `True`

when comparing incompatible types like `"a" == 1`

and `"a" != 1`

.
For a long time these gave `DeprecationWarning`

or `FutureWarning`

.

(gh-22707)

## Compatibility notes#

When comparing datetimes and timedelta using

`np.equal`

or`np.not_equal`

numpy previously allowed the comparison with`casting="unsafe"`

. This operation now fails. Forcing the output dtype using the`dtype`

kwarg can make the operation succeed, but we do not recommend it.(gh-22707)

### Cython `long_t`

and `ulong_t`

removed#

`long_t`

and `ulong_t`

were aliases for `longlong_t`

and `ulonglong_t`

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).
If C `long`

is desired, use plain `long`

or `npy_long`

.
`cnp.int_t`

is also `long`

(NumPy’s default integer). However, `long`

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.)

(gh-22637)

### Changed error message and type for bad `axes`

argument to `ufunc`

#

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.
A `TypeError`

will still be raised for invalid input types.

(gh-22675)

## New Features#

### NumPy now has an `np.exceptions`

namespace#

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.

(gh-22644)

## Improvements#

### Fix power of complex zero#

`np.power`

now returns a different result for `0^{non-zero}`

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 `0+0j`

or `0-0j`

.

(gh-18535)

### New `DTypePromotionError`

#

NumPy now has a new `DTypePromotionError`

which is used when two
dtypes cannot be promoted to a common one, for example:

```
np.result_type("M8[s]", np.complex128)
```

raises this new exception.

(gh-22707)