Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
I've made a PR for this. The commit message is
Deal with subclasses of ndarray, like pandas.Series and matrix.
Subclasses may not define the new keyword keepdims or deal
gracefully with ufuncs in all their forms. This is solved by
throwing the problem onto the np.sum, np.any, etc. functions
that have ugly hacks to deal with the problem.
Settle handling of all-nan slices.
nanmax, nanmin -- Raise warning, return NaN for slice.
nanargmax, nanargmin -- Raise ValueError.
nansum -- Return 0 for slice.
nanmean, nanvar, nanstd -- Raise warning, return NaN for slice.
Make NaN functions work for scalar arguments.
This may seem silly, but it removes a check for special cases.
Update tests
Deal with new all-nan handling.
Test with matrix class as example of subclass without keepdims.
Test with scalar arguments.
Note that 1.7 already raises a ValueError for nanarg{max, min} on account
of casting rules that don't allow nans to be cast to ints. This just makes
the same hold true for scalar returns.
If there are no objections, this will go into 1.9 as a starting point and
be backported to 1.8.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
Hello,
sorry, I don't know where exactly jump in in the thread, it is getting
quite long and articulated...
On 02/10/2013 21:19, Charles R Harris wrote:
The main problem I had was deciding what arg{max, min} should return as
the return value is an integer. I like your suggestion of returning 0.
What about returning -1? It is still an integer (on my numpy version the
return value is a signed integer), it still has the property that
a[np.argmin(a)] == nan for a of only nans, but it is easily identifiable
as an anomalous return value if needed.
One further possibility is to add a keyword 'raise' to make the behavior
selectable.
I don't like function arguments that change the function behavior.
Cheers,
Daniele
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On 03/10/2013 13:56, Charles R Harris wrote:
On Thu, Oct 3, 2013 at 4:06 AM, Daniele Nicolodi dani...@grinta.net
mailto:dani...@grinta.net wrote:
Hello,
sorry, I don't know where exactly jump in in the thread, it is getting
quite long and articulated...
On 02/10/2013 21:19, Charles R Harris wrote:
The main problem I had was deciding what arg{max, min} should
return as
the return value is an integer. I like your suggestion of returning 0.
What about returning -1? It is still an integer (on my numpy version the
return value is a signed integer), it still has the property that
a[np.argmin(a)] == nan for a of only nans, but it is easily identifiable
as an anomalous return value if needed.
The problem is that -1 is a valid index, whereas intp.min will always be
out of range and lead to an IndexError if used.
If the goal is to have an error raised, just do it and do not rely on
the fact that using an invalid index will soon or later result in an error.
My proposal was a compromise to the proposal of returning 0. 0 is a
valid index that cannot be distinguished from a valid return value, -1
is a valid index but can be easily distinguished as a special case.
I don't have a strong preference between
try:
i = np.nanargmin(a)
except ValueError:
something()
and
i = np.nanargmin(a)
if i 0:
something()
but definitely I don't like returning 0:
i = np.nanargmin(a)
if i == 0:
# uhm, wait, is the minimum at index 0 or the array is all nans?!?
if np.isnan(a[0]):
something()
Cheers,
Daniele
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Thu, Oct 3, 2013 at 6:06 AM, Daniele Nicolodi dani...@grinta.net wrote:
Hello,
sorry, I don't know where exactly jump in in the thread, it is getting
quite long and articulated...
On 02/10/2013 21:19, Charles R Harris wrote:
The main problem I had was deciding what arg{max, min} should return as
the return value is an integer. I like your suggestion of returning 0.
What about returning -1? It is still an integer (on my numpy version the
return value is a signed integer), it still has the property that
a[np.argmin(a)] == nan for a of only nans, but it is easily identifiable
as an anomalous return value if needed.
This actually makes a lot of sense. We would never return -1 for any other
reason. And if it is used for indexing anywhere else, that's (mostly) ok. A
problem might occur if the indexes gathered from this function are then
used to define slices. But I can't really convince myself that it would be
all that terrible in that case, too. Documentation will be paramount here.
Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Thu, Oct 3, 2013 at 9:10 AM, Benjamin Root ben.r...@ou.edu wrote:
On Thu, Oct 3, 2013 at 6:06 AM, Daniele Nicolodi dani...@grinta.net wrote:
Hello,
sorry, I don't know where exactly jump in in the thread, it is getting
quite long and articulated...
On 02/10/2013 21:19, Charles R Harris wrote:
The main problem I had was deciding what arg{max, min} should return as
the return value is an integer. I like your suggestion of returning 0.
What about returning -1? It is still an integer (on my numpy version the
return value is a signed integer), it still has the property that
a[np.argmin(a)] == nan for a of only nans, but it is easily identifiable
as an anomalous return value if needed.
This actually makes a lot of sense. We would never return -1 for any other
reason. And if it is used for indexing anywhere else, that's (mostly) ok. A
problem might occur if the indexes gathered from this function are then used
to define slices. But I can't really convince myself that it would be all
that terrible in that case, too. Documentation will be paramount here.
Please, no. It's another thing to remember and another way to shoot
yourself in the foot and introduce casual bugs.
FWIW, my vote is to raise an error or return a nan, which will likely
eventually raise an error. If I have all nans, it's usually the case
that something's off, and I'd like to know sooner rather than later.
Skipper
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
snip Please, no. It's another thing to remember and another way to shoot yourself in the foot and introduce casual bugs. FWIW, my vote is to raise an error or return a nan, which will likely eventually raise an error. If I have all nans, it's usually the case that something's off, and I'd like to know sooner rather than later. Here is what I have currently implemented. First, define an AllNanError class AllNanError(ValueError): def __init__(self, msg, result): ValueError.__init__(self, msg) self.result = result For nanmax/nanmin/nanargmax/nanargmin this error is raised for all-nan axis and the result is attached. The exception can then be caught and the result examined. A ValueError is what amax, amin return for empty arrays. For nanmax/nanmin the result for an empty slice is nan. For argnanmax/argnanmin the result of an empty slice is -1, which is easier to read and remember than intp.min. A ValueError is what argmin, argmax currently return for empty arrays. Note that both of these functions can give wrong results if they contain some min/max values respectively. That is an old bug and I haven't fixed it. The nanmean/nanvar/nanstd functions currently raise a warning for all-nan slices and the result for such is nan. These could also be made to raise an error. Thoughts? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Thu, Oct 3, 2013 at 7:59 PM, Charles R Harris charlesr.har...@gmail.com wrote: snip Please, no. It's another thing to remember and another way to shoot yourself in the foot and introduce casual bugs. FWIW, my vote is to raise an error or return a nan, which will likely eventually raise an error. If I have all nans, it's usually the case that something's off, and I'd like to know sooner rather than later. Here is what I have currently implemented. First, define an AllNanError class AllNanError(ValueError): def __init__(self, msg, result): ValueError.__init__(self, msg) self.result = result For nanmax/nanmin/nanargmax/nanargmin this error is raised for all-nan axis and the result is attached. The exception can then be caught and the result examined. A ValueError is what amax, amin return for empty arrays. For nanmax/nanmin the result for an empty slice is nan. For argnanmax/argnanmin the result of an empty slice is -1, which is easier to read and remember than intp.min. A ValueError is what argmin, argmax currently return for empty arrays. Note that both of these functions can give wrong results if they contain some min/max values respectively. That is an old bug and I haven't fixed it. The nanmean/nanvar/nanstd functions currently raise a warning for all-nan slices and the result for such is nan. These could also be made to raise an error. Thoughts? Is this intended for 1.8 or master? -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Thu, Oct 3, 2013 at 1:11 PM, Nathaniel Smith n...@pobox.com wrote: On Thu, Oct 3, 2013 at 7:59 PM, Charles R Harris charlesr.har...@gmail.com wrote: snip Please, no. It's another thing to remember and another way to shoot yourself in the foot and introduce casual bugs. FWIW, my vote is to raise an error or return a nan, which will likely eventually raise an error. If I have all nans, it's usually the case that something's off, and I'd like to know sooner rather than later. Here is what I have currently implemented. First, define an AllNanError class AllNanError(ValueError): def __init__(self, msg, result): ValueError.__init__(self, msg) self.result = result For nanmax/nanmin/nanargmax/nanargmin this error is raised for all-nan axis and the result is attached. The exception can then be caught and the result examined. A ValueError is what amax, amin return for empty arrays. For nanmax/nanmin the result for an empty slice is nan. For argnanmax/argnanmin the result of an empty slice is -1, which is easier to read and remember than intp.min. A ValueError is what argmin, argmax currently return for empty arrays. Note that both of these functions can give wrong results if they contain some min/max values respectively. That is an old bug and I haven't fixed it. The nanmean/nanvar/nanstd functions currently raise a warning for all-nan slices and the result for such is nan. These could also be made to raise an error. Thoughts? Is this intended for 1.8 or master? I was thinking both. The nanarg* functions are changing behavior anyway, so might as well get it all done in 1.8. I also think there will need to be an rc2 in anycase. the current non-nan aware mean/var/std only raise warnings on insufficient degrees of freedom and return nan. That's a bit of a change, they used to return nans, negative numbers, and other things in that situation. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On 03/10/2013 20:59, Charles R Harris wrote: Here is what I have currently implemented. First, define an AllNanError class AllNanError(ValueError): def __init__(self, msg, result): ValueError.__init__(self, msg) self.result = result For nanmax/nanmin/nanargmax/nanargmin this error is raised for all-nan axis and the result is attached. The exception can then be caught and the result examined. A ValueError is what amax, amin return for empty arrays. For nanmax/nanmin the result for an empty slice is nan. For argnanmax/argnanmin the result of an empty slice is -1, which is easier to read and remember than intp.min. I think an error in this cases would be less confusing. A ValueError is what argmin, argmax currently return for empty arrays. Note that both of these functions can give wrong results if they contain some min/max values respectively. That is an old bug and I haven't fixed it. The nanmean/nanvar/nanstd functions currently raise a warning for all-nan slices and the result for such is nan. These could also be made to raise an error. I think an error in that case would be more consistent. Cheers, Daniele ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Thu, Oct 3, 2013 at 8:40 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Oct 3, 2013 at 1:11 PM, Nathaniel Smith n...@pobox.com wrote: On Thu, Oct 3, 2013 at 7:59 PM, Charles R Harris charlesr.har...@gmail.com wrote: snip Please, no. It's another thing to remember and another way to shoot yourself in the foot and introduce casual bugs. FWIW, my vote is to raise an error or return a nan, which will likely eventually raise an error. If I have all nans, it's usually the case that something's off, and I'd like to know sooner rather than later. Here is what I have currently implemented. First, define an AllNanError class AllNanError(ValueError): def __init__(self, msg, result): ValueError.__init__(self, msg) self.result = result For nanmax/nanmin/nanargmax/nanargmin this error is raised for all-nan axis and the result is attached. The exception can then be caught and the result examined. A ValueError is what amax, amin return for empty arrays. For nanmax/nanmin the result for an empty slice is nan. For argnanmax/argnanmin the result of an empty slice is -1, which is easier to read and remember than intp.min. A ValueError is what argmin, argmax currently return for empty arrays. Note that both of these functions can give wrong results if they contain some min/max values respectively. That is an old bug and I haven't fixed it. The nanmean/nanvar/nanstd functions currently raise a warning for all-nan slices and the result for such is nan. These could also be made to raise an error. Thoughts? Is this intended for 1.8 or master? I was thinking both. The nanarg* functions are changing behavior anyway, so might as well get it all done in 1.8. I also think there will need to be an rc2 in anycase. This is obviously a complicated and contentious enough issue that I think for 1.8 we need to punt rather than try to force something out under time pressure. We obviously need an rc2 anyway with all the other stuff that's come in, but for 1.8 I'm going to suggest again we go with: - leave nanmax/nanmin as is - make nanargmax/nanargmin just raise a simple ValueError on all-nans (so that same as 1.7 for operations on multiple subarrays; the only difference would be that for 1d operations 1.8 would raise where 1.7 returned nan). I'm not saying we should stick with this forever, but it solves the immediately problem that started this whole mess, and I can't see how anyone could object to it as a temporary solution -- it's basically the same as what 1.7 does. And it clears the deck for whatever cleverer thing we come up with in master. Does that make sense? I'm not going to out-right say -1 on doing anything else for 1.8, but the longer this drags on the more tempting it becomes, just because who can really evaluate a more interesting proposal with the release breathing down their neck? the current non-nan aware mean/var/std only raise warnings on insufficient degrees of freedom and return nan. That's a bit of a change, they used to return nans, negative numbers, and other things in that situation. Seems reasonable to me. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
+1 to making the nan functions consistent with the non-nan functions.
On 2 Oct 2013 17:03, Charles R Harris charlesr.har...@gmail.com wrote:
Hi All,
The question is what to do when all-nan slices are encountered in the
nan{max,min} and nanarg{max, min} functions. Currently in 1.8.0, the first
returns nan and raises a warning, the second returns intp.min and raises a
warning. It is proposed that the nanarg{max, min} functions, and possibly
the nan{max, min} also, raise an error instead. Raising errors would be
consistent with the behavior of the arg{max, min} and amax/amin functions
when they encounter empty arrays. OTOH, now that we no longer support
Python 2.4/2.5 the catch_warnings context manager can serve the same
purpose by changing the warnings into exceptions. So, what to do?
Thoughts?
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On 2 Oct 2013 18:04, Charles R Harris charlesr.har...@gmail.com wrote:
The question is what to do when all-nan slices are encountered in the
nan{max,min} and nanarg{max, min} functions. Currently in 1.8.0, the first
returns nan and raises a warning, the second returns intp.min and raises a
warning. It is proposed that the nanarg{max, min} functions, and possibly
the nan{max, min} also, raise an error instead.
I agree with Nathan; this sounds like more reasonable behaviour to me.
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Wed, Oct 2, 2013 at 12:37 PM, Stéfan van der Walt ste...@sun.ac.za wrote:
On 2 Oct 2013 18:04, Charles R Harris charlesr.har...@gmail.com wrote:
The question is what to do when all-nan slices are encountered in the
nan{max,min} and nanarg{max, min} functions. Currently in 1.8.0, the first
returns nan and raises a warning, the second returns intp.min and raises a
warning. It is proposed that the nanarg{max, min} functions, and possibly
the nan{max, min} also, raise an error instead.
I agree with Nathan; this sounds like more reasonable behaviour to me.
If I understand what you are proposing
-1 on raising an error with nan{max, min},
an empty array is empty in all columns
an array with nans, might be empty in only some columns.
as far as I understand, nan{max, min} only make sense with arrays that
can hold a nan, so we can return nans.
If a user calls with ints or bool, then there are either no nans or
the array is empty, and I don't care.
---
aside
with nanarg{max, min} I would just return 0 in an all nan column,
since the max or min is nan, and one is at zero.
(but I'm not arguing)
Josef
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Wed, Oct 2, 2013 at 10:56 AM, josef.p...@gmail.com wrote:
On Wed, Oct 2, 2013 at 12:37 PM, Stéfan van der Walt ste...@sun.ac.za
wrote:
On 2 Oct 2013 18:04, Charles R Harris charlesr.har...@gmail.com
wrote:
The question is what to do when all-nan slices are encountered in the
nan{max,min} and nanarg{max, min} functions. Currently in 1.8.0, the
first
returns nan and raises a warning, the second returns intp.min and
raises a
warning. It is proposed that the nanarg{max, min} functions, and
possibly
the nan{max, min} also, raise an error instead.
I agree with Nathan; this sounds like more reasonable behaviour to me.
If I understand what you are proposing
-1 on raising an error with nan{max, min},
an empty array is empty in all columns
an array with nans, might be empty in only some columns.
as far as I understand, nan{max, min} only make sense with arrays that
can hold a nan, so we can return nans.
That was my original thought.
If a user calls with ints or bool, then there are either no nans or
the array is empty, and I don't care.
---
aside
with nanarg{max, min} I would just return 0 in an all nan column,
since the max or min is nan, and one is at zero.
(but I'm not arguing)
That is an interesting proposal. I like it.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Wed, Oct 2, 2013 at 1:05 PM, Charles R Harris
charlesr.har...@gmail.comwrote:
On Wed, Oct 2, 2013 at 10:56 AM, josef.p...@gmail.com wrote:
On Wed, Oct 2, 2013 at 12:37 PM, Stéfan van der Walt ste...@sun.ac.za
wrote:
On 2 Oct 2013 18:04, Charles R Harris charlesr.har...@gmail.com
wrote:
The question is what to do when all-nan slices are encountered in the
nan{max,min} and nanarg{max, min} functions. Currently in 1.8.0, the
first
returns nan and raises a warning, the second returns intp.min and
raises a
warning. It is proposed that the nanarg{max, min} functions, and
possibly
the nan{max, min} also, raise an error instead.
I agree with Nathan; this sounds like more reasonable behaviour to me.
If I understand what you are proposing
-1 on raising an error with nan{max, min},
an empty array is empty in all columns
an array with nans, might be empty in only some columns.
as far as I understand, nan{max, min} only make sense with arrays that
can hold a nan, so we can return nans.
That was my original thought.
If a user calls with ints or bool, then there are either no nans or
the array is empty, and I don't care.
---
aside
with nanarg{max, min} I would just return 0 in an all nan column,
since the max or min is nan, and one is at zero.
(but I'm not arguing)
That is an interesting proposal. I like it.
Chuck
And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a)
(ignoring the silly detail that you can't do an equality on nans).
Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On 2 Oct 2013 19:14, Benjamin Root ben.r...@ou.edu wrote: And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) (ignoring the silly detail that you can't do an equality on nans). Why do you call this a silly detail? It seems to me a fundamental flaw to this approach. Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt ste...@sun.ac.za wrote: On 2 Oct 2013 19:14, Benjamin Root ben.r...@ou.edu wrote: And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) (ignoring the silly detail that you can't do an equality on nans). Why do you call this a silly detail? It seems to me a fundamental flaw to this approach. a nan is a nan is a NaN np.testing.assert_equal([0, np.nan], [0, np.nan]) Josef Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Wed, Oct 2, 2013 at 2:49 PM, josef.p...@gmail.com wrote: On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt ste...@sun.ac.za wrote: On 2 Oct 2013 19:14, Benjamin Root ben.r...@ou.edu wrote: And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) (ignoring the silly detail that you can't do an equality on nans). Why do you call this a silly detail? It seems to me a fundamental flaw to this approach. a nan is a nan is a NaN np.testing.assert_equal([0, np.nan], [0, np.nan]) and the functions have nan in their names nan in - NaN out what about nanmean, nansum, ...? Josef Josef Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt ste...@sun.ac.zawrote: On 2 Oct 2013 19:14, Benjamin Root ben.r...@ou.edu wrote: And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) (ignoring the silly detail that you can't do an equality on nans). Why do you call this a silly detail? It seems to me a fundamental flaw to this approach. Just saying that it conceptually makes sense, even if the exact code I used wouldn't be perfectly correct. Because these are NaN functions, it means that the users are already aware of the need to handle nans appropriately. Just because you can't actually do equality between two NaNs in the same way as one can do with numbers does not invalidate the concept. Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Wed, Oct 2, 2013 at 7:51 PM, josef.p...@gmail.com wrote: On Wed, Oct 2, 2013 at 2:49 PM, josef.p...@gmail.com wrote: On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt ste...@sun.ac.za wrote: On 2 Oct 2013 19:14, Benjamin Root ben.r...@ou.edu wrote: And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a) (ignoring the silly detail that you can't do an equality on nans). Why do you call this a silly detail? It seems to me a fundamental flaw to this approach. a nan is a nan is a NaN np.testing.assert_equal([0, np.nan], [0, np.nan]) and the functions have nan in their names nan in - NaN out This makes no sense :-). The nan in the names means pretend the nans aren't there, not please scatter nans in the output! These are just vectorized operations that can fail in some cases and not others, there's nothing special about the fact that the function's definition also involves nan. what about nanmean, nansum, ...? They do the same thing as mean([]), sum([]), etc., which are well-defined. (nan and 0 respectively.) -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Wed, Oct 2, 2013 at 12:51 PM, josef.p...@gmail.com wrote:
On Wed, Oct 2, 2013 at 2:49 PM, josef.p...@gmail.com wrote:
On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt ste...@sun.ac.za
wrote:
On 2 Oct 2013 19:14, Benjamin Root ben.r...@ou.edu wrote:
And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a)
(ignoring the silly detail that you can't do an equality on nans).
Why do you call this a silly detail? It seems to me a fundamental flaw
to
this approach.
a nan is a nan is a NaN
np.testing.assert_equal([0, np.nan], [0, np.nan])
and the functions have nan in their names
nan in - NaN out
what about nanmean, nansum, ...?
nanmean returns nan for empty slices while nansum returns nan in 1.8,
consistent with previous behavior, and will return 0 in 1.9.
The main problem I had was deciding what arg{max, min} should return as the
return value is an integer. I like your suggestion of returning 0.
One further possibility is to add a keyword 'raise' to make the behavior
selectable.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On Wed, Oct 2, 2013 at 8:19 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Wed, Oct 2, 2013 at 12:51 PM, josef.p...@gmail.com wrote:
On Wed, Oct 2, 2013 at 2:49 PM, josef.p...@gmail.com wrote:
On Wed, Oct 2, 2013 at 2:05 PM, Stéfan van der Walt ste...@sun.ac.za
wrote:
On 2 Oct 2013 19:14, Benjamin Root ben.r...@ou.edu wrote:
And it is logically consistent, I think. a[nanargmax(a)] == nanmax(a)
(ignoring the silly detail that you can't do an equality on nans).
Why do you call this a silly detail? It seems to me a fundamental flaw
to
this approach.
a nan is a nan is a NaN
np.testing.assert_equal([0, np.nan], [0, np.nan])
and the functions have nan in their names
nan in - NaN out
what about nanmean, nansum, ...?
nanmean returns nan for empty slices while nansum returns nan in 1.8,
consistent with previous behavior, and will return 0 in 1.9.
The main problem I had was deciding what arg{max, min} should return as the
return value is an integer. I like your suggestion of returning 0.
I don't understand the justification for returning 0 at all. nan is
not the max or min or the array. Even if argmax/argmin return nan[1],
it's just a special code meaning undefined, it has no relation to
the nans inside the array. So returning 0 just feels to me like pure
we have to return *something* and this something! (that we can kind
of justify is no-one looks too hard!). This exactly the impulse that
when in doubt refuse the temptation to guess is written to
counteract...
Seriously what user calls nanargmax and *wants* to get pointed to a
random nan inside the array? Isn't the whole point of calling
nanargmax to avoid exactly this situation?
-n
[1] It seems clear that we shouldn't mess about with argmax/argmin for
1.8, but my guess is that in the long run we'll come up with a more
general convention for signalling partial errors, and eventually want
to switch nanargmax/nanargmin to using that.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Behavior of nan{max, min} and nanarg{max, min} for all-nan slices.
On 2 Oct 2013 21:19, Charles R Harris charlesr.har...@gmail.com wrote:
The main problem I had was deciding what arg{max, min} should return as
the return value is an integer. I like your suggestion of returning 0.
This doesn't allow the user to know the difference between valid and
invalid output, does it?
One further possibility is to add a keyword 'raise' to make the behavior
selectable.
Preferably just pick a sensible default.
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
