-
-
Notifications
You must be signed in to change notification settings - Fork 18.5k
Handle NaN in array_with_unit_to_datetime #48705
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -298,6 +298,10 @@ def array_with_unit_to_datetime( | |
iresult = values.astype("i8", copy=False) | ||
# fill missing values by comparing to NPY_NAT | ||
mask = iresult == NPY_NAT | ||
# Trying to Convert NaN to integer results in undefined | ||
# behaviour, so handle it explicitly | ||
if values.dtype.kind == "f": | ||
mask |= values != values | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. on the relevant hardware, what do you get for iresult when values is [np.nan]? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. $ python3
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @seberg is getting 9223372036854775807 instead of 9223372036854775808 weird or is it just me? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 42 would also be a valid result. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. NumPy has no guarantees for However, NumPy does have guarantees for I am not sure what you mean with:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No sure why you ask, you already gave the answer above. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Misread the code. In any case, NumPy handles the cast correctly for datetime64, even if it uses a slower/weirder code path (currently, this is very much fixable!). So the question is wether it doesn't make more sense to cast to datetime64. Further, the above may cause floating-point warnings in newer NumPy versions, which is something you probably don't want to see! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @andreas-schwab i'd be OK with either a) investigating seberg's suggestions for a more in-depth "right way" to handle this, or b) adding a comment pointing back to this thread and being done with it There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is fine. can you add a comment pointing back to this PR and a few words about why we're doing this |
||
iresult[mask] = 0 | ||
fvalues = iresult.astype("f8") * mult | ||
need_to_iterate = False | ||
|
Uh oh!
There was an error while loading. Please reload this page.