Hmm... IIRC, there are three treatments of nan -> int, the one shown, conversion to 0, and raising an error. We should try to rationalize things at some point. For the current behavior, I agree that raising an error would be better.

I can't say I really understand how np.nan really works, but it would be cool if there was an equivalent np.intnan or something that would work with integer arrays - NaNs are pretty useful, and it'd be nice to be able to use them with integers too.

The problem with integers as that there aren't any left over, whereas for floating point there are bit patterns not used by any actual floating point number.

Ah, fair enough. I guess it would take a change in python itself to specify that e.g -9223372036854775808 wasn't a number, and could be used for nan or inf or similar? And that's almost certainly not going to happen...

Google "missing values" to see how various (statistical) projects deal with similar needs. Note that missing values are not quite the same as not-a-number.

This will now at the very least give a RuntimeWarning on main (still a while until a next release).

There is still a more general issue whether:

• Full should allow unsafe casts at all (but we do in practically all filling functions)
• Whether integer casts should be more agressive then giving a warning or sanitize the values.

At least for the second part, I kept gh-14412 as an issue open. So closing this for now, but please feel free to open a new issue if you feel it is important (and there is no current duplicate; if there is a duplicate just comment there!)