Yeah, I have been wondering about that myself. But on the other hand, blowing up casting options is a bit annoying. For integers specifically, it could be part of a error flags or so (i.e. if we had integer overflow errors, that could clearly handle this part).

I agree about raising an error. Here is a simpler example to follow:

import numpy as np

arr2D = [
    [9,9,9],
    [9,np.nan,9],
    [9,9,9]
]

arr2D = np.array(arr2D)
arr2D = arr2D.astype('int32')

>>> arr2D
array([[          9,           9,           9],
       [          9, -2147483648,           9],
       [          9,           9,           9]], dtype=int32)

⚠️⚠️⚠️ -2147483648 ⚠️⚠️⚠️

I think this is C's int minimum?

@aiqc that returns undefined behaviour (as defind by the C standard). It is a bit scary/annoying, but right now you must not rely on the minimum value to be returned. Typical values are either min-int or 0. Most importantly, IIRC, tthis can fluctuate on the same computer (because the CPU has different ways to do the same thing except for this type of undefined behaviour, and we switch depending on whats faster – that is, we may or may not use SIMD instructions).

xref gh-19248. If we would not silence floating point warnings would at least warn you about this happening:

In [1]: import numpy as np
   ...: 
   ...: arr2D = [
   ...:     [9,9,9],
   ...:     [9,9e100,9],
   ...:     [9,9,9]
   ...: ]

In [2]: np.positive(arr2D, casting="unsafe", signature="l")
<ipython-input-2-7fc1fa2347c4>:1: RuntimeWarning: invalid value encountered in positive
  np.positive(arr2D, casting="unsafe", signature="l")
Out[2]: 
array([[                   9,                    9,                    9],
       [                   9, -9223372036854775808,                    9],
       [                   9,                    9,                    9]])

@seberg if it can’t be reliably parsed then that’s even more reason to raise error on dtype conversion?

Yes, I don't mind raising an error, but I think a warning would be a good improvement. There are two things we may need to consider:

• There may be quite a bit of code assuming it gets the smallest possible int value (and gets away with that, even if it isn't always true)
• It would be good to know if there are any speed implications to sanitizing the values. Even if we just ensure the result is indeed the smallest possible int.

We are now giving a warning in this cases after gh-21437. Lets keep this one issue open about possibly raising an error. Or even sanitizing the output.
(Although, I currently doubt it will top the priority list in the forseeable future.)

Pinging this, as we discovered some failures in our code due to:

np.full(n, np.nan, dtype=np.int64)

returning an architecture-dependent value (-MAX_INT on Linux x86-64, 0 on macos arm64), as expected for an undefined operation. I strongly support making this raise, and/or adding an unsafe_cast option to seterr for all float->int casts, so that users can choose to raise for all such unsafe casts. I don't see how anyone would want to maintain the existing undefined non-finite value casting behavior.

The warning message added earlier is a start, but it can be hard to track down just where in the code that warning is coming from. If one could make float->int casts always, that would at least make it very obvious what needed to be fixed in the user code.

That example fails in new NumPy versions @parejkoj. Although, not if you use e.g. np.float64(np.nan).

Oh, I'm glad that that's now a failure! We're currently on numpy version 1.26.4, and working on compatibility checks for 2.0. Is there a PR with this particular fix I could look at?

I'm not sure what you mean by "not if you use np.float64(np.nan)", though?

If you pass a NumPy Nan, rather than the Python float nan it will cast normally, and normal casts are still allowed/unchanged.