Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unexpected behaviour on full_like(<int_array>, nan) #8017

Closed
naught101 opened this issue Sep 5, 2016 · 6 comments
Closed

unexpected behaviour on full_like(<int_array>, nan) #8017

naught101 opened this issue Sep 5, 2016 · 6 comments

Comments

@naught101
Copy link

>>> np.full_like(np.array([1,0]), np.nan)
array([-9223372036854775808, -9223372036854775808])

Normally, conversion of an NaN to an int fails:

>>> np.int(np.nan) 
ValueError: cannot convert float NaN to integer

I suspect the full_like behaviour should similarly raise an error. I'm not sure how common this behaviour is.

@charris
Copy link
Member

charris commented Sep 5, 2016

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.

@naught101
Copy link
Author

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.

@charris
Copy link
Member

charris commented Sep 13, 2016

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.

@naught101
Copy link
Author

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

@charris
Copy link
Member

charris commented Sep 13, 2016

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.

@seberg
Copy link
Member

seberg commented Jun 14, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants