in(np.nan) on python 2.6
All, Sorry to bump my own post, and I was kinda threadjacking anyway:
Some functions of numy.ma (eg, ma.max, ma.min...) accept explicit outputs that may not be MaskedArrays. When such an explicit output is not a MaskedArray, a value that should have been masked is transformed into np.nan.
That worked great in 2.5, with np.nan automatically transformed to 0 when the explicit output had a int dtype. With Python 2.6, a ValueError is raised instead, as np.nan can no longer be casted to int.
What should be the recommended behavior in this case ? Raise a ValueError or some other exception, to follow the new Python2.6 convention, or silently replace np.nan by some value acceptable by int dtype (0, or something else) ?
Thanks for any suggestion, P.
On Nov 25, 2008, at 12:23 PM, Pierre GM wrote:
All, Sorry to bump my own post, and I was kinda threadjacking anyway:
Some functions of numy.ma (eg, ma.max, ma.min...) accept explicit outputs that may not be MaskedArrays. When such an explicit output is not a MaskedArray, a value that should have been masked is transformed into np.nan.
That worked great in 2.5, with np.nan automatically transformed to 0 when the explicit output had a int dtype. With Python 2.6, a ValueError is raised instead, as np.nan can no longer be casted to int.
What should be the recommended behavior in this case ? Raise a ValueError or some other exception, to follow the new Python2.6 convention, or silently replace np.nan by some value acceptable by int dtype (0, or something else) ?
Second bump, sorry. Any consensus on what the behavior should be ? Raise a ValueError (even in 2.5, therefore risking to break something) or just go with the flow and switch np.nan to an acceptable value (like 0), under the hood ? I'd like to close the corresponding ticket...
On Thu, Dec 4, 2008 at 11:14 AM, Pierre GM pgmdevlist@gmail.com wrote:
Raise a ValueError (even in 2.5, therefore risking to break something)
+1
On Thu, Dec 4, 2008 at 2:40 PM, Jarrod Millman millman@berkeley.edu wrote:
On Thu, Dec 4, 2008 at 11:14 AM, Pierre GM pgmdevlist@gmail.com wrote:
Raise a ValueError (even in 2.5, therefore risking to break something)
+1
+1
I'm not yet a serious user of numpy/scipy, but when debugging the discrete distributions, it took me a while to figure out that some mysteriously appearing zeros were nans that were silently converted during casting to int.
In matlab, I encode different types of missing values (in the data) by numbers that I know are not in my dataset, e.g -2**20, -2**21,... but that depends on the dataset. (hand made nan handling, before data is cleaned). When I see then a "weird" number, I know that there is a problem, if it the nan is zero, I wouldn't know if it's a missing value or really a zero.
Josef
On Dec 4, 2008, at 3:24 PM, josef.pktd@gmail.com wrote:
On Thu, Dec 4, 2008 at 2:40 PM, Jarrod Millman millman@berkeley.edu wrote:
On Thu, Dec 4, 2008 at 11:14 AM, Pierre GM pgmdevlist@gmail.com wrote:
Raise a ValueError (even in 2.5, therefore risking to break something)
+1
+1
OK then, I'll do that and update the SVN later tonight or early tmw...
josef.pktd@gmail.com wrote:
Raise a ValueError (even in 2.5, therefore risking to break something)
+1 as well
it took me a while to figure out that some mysteriously appearing zeros were nans that were silently converted during casting to int.
and this is why -- a zero is a perfectly valid and useful number, NaN should never get cast to a zero (or any other valid number) unless the user explicitly asks it to be.
I think the right choice was made for python 2.6 here.
-Chris
participants (4)
-
Christopher Barker -
Jarrod Millman -
josef.pktd＠gmail.com -
Pierre GM