What is the different between nanmin and min ?
Hi, I noticed that min and max already ignore Nan, which raises the question: why are there nanmin and nanmax functions ? cheers, David
Hi, I encountered cases where numpy.min() returned nan when the first and the last values were nan. Didn't know of nanmin(), but I'll use them now ! Matthieu 2007/7/17, David Cournapeau <david@ar.media.kyoto-u.ac.jp>:
Hi,
I noticed that min and max already ignore Nan, which raises the question: why are there nanmin and nanmax functions ?
cheers,
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Matthieu Brucher wrote:
Hi,
I encountered cases where numpy.min() returned nan when the first and the last values were nan. Didn't know of nanmin(), but I'll use them now ! Mmh, interesting. Indeed, a quick test shows that as long as the last value of a rank 1 array is not Nan, min ignore nan.
import numpy a = 0.1 * numpy.arange(10) numpy.min(a) a[:9] = numpy.nan numpy.min(a) # ignore Nan a = 0.1 * numpy.arange(10) a[-1] = numpy.nan numpy.min(a) # Does not ignore Nan cheers, David
On 7/17/07, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
I noticed that min and max already ignore Nan, which raises the question: why are there nanmin and nanmax functions ?
Using min and max when you have NaNs is dangerous. Here's an example:
x = M.matrix([[ 1.0, 2.0, M.nan]]) x.min() 1.0
x = M.matrix([[ M.nan, 2.0, 1.0]]) x.min() nan
I wish that min and max ignored NaNs. For me taking the time to check for NaNs (slowing down min and max) is worth it. But it seems like most people disagree. So I use nanmin and nanmax instead.
On 7/17/07, Keith Goodman <kwgoodman@gmail.com> wrote:
On 7/17/07, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
I noticed that min and max already ignore Nan, which raises the question: why are there nanmin and nanmax functions ?
Using min and max when you have NaNs is dangerous. Here's an example:
x = M.matrix([[ 1.0, 2.0, M.nan]]) x.min() 1.0
x = M.matrix([[ M.nan, 2.0, 1.0]]) x.min() nan
I wish that min and max ignored NaNs. For me taking the time to check for NaNs (slowing down min and max) is worth it. But it seems like most people disagree. So I use nanmin and nanmax instead.
The time is one issue. Another is that ignoring NaNs is only correct if you are treating NaNs as missing values. If instead you are treating them as non numbers, the results of some bogus computation, then raising an error is a more appropriate response. If one was going to take the time to check for NaNs, one strategy that I would probably support would be to ignore the NaNs, but set the invalid flag. If the error state for invalid was set to ignore, then this would work as the missing value camp likes, otherwise it would raise an error or signal a warning. -- . __ . |-\ . . tim.hochberg@ieee.org
On 7/17/07, Timothy Hochberg <tim.hochberg@ieee.org> wrote:
The time is one issue. Another is that ignoring NaNs is only correct if you are treating NaNs as missing values. If instead you are treating them as non numbers, the results of some bogus computation, then raising an error is a more appropriate response. If one was going to take the time to check for NaNs, one strategy that I would probably support would be to ignore the NaNs, but set the invalid flag. If the error state for invalid was set to ignore, then this would work as the missing value camp likes, otherwise it would raise an error or signal a warning.
That sounds great. Would a change like that have to wait until 1.1?
Timothy Hochberg wrote:
The time is one issue. Another is that ignoring NaNs is only correct if you are treating NaNs as missing values. If instead you are treating them as non numbers, the results of some bogus computation, then raising an error is a more appropriate response. If one was going to take the time to check for NaNs, one strategy that I would probably support would be to ignore the NaNs, but set the invalid flag. If the error state for invalid was set to ignore, then this would work as the missing value camp likes, otherwise it would raise an error or signal a warning.
I'd almost be willing to make max() and min() always ignore quiet NaNs. The C99 standard requires this, for example, (c.f. section F.9.9.2 of the C99 standard). -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On 7/18/07, Robert Kern <robert.kern@gmail.com> wrote:
Timothy Hochberg wrote:
The time is one issue. Another is that ignoring NaNs is only correct if you are treating NaNs as missing values. If instead you are treating them as non numbers, the results of some bogus computation, then raising an error is a more appropriate response. If one was going to take the time to check for NaNs, one strategy that I would probably support would be to ignore the NaNs, but set the invalid flag. If the error state for invalid was set to ignore, then this would work as the missing value camp likes, otherwise it would raise an error or signal a warning.
I'd almost be willing to make max() and min() always ignore quiet NaNs. The C99 standard requires this, for example, (c.f. section F.9.9.2 of the C99 standard).
Wow! It sure does. That surprises me as it seems antithetical to my understanding of the concept of NaNs being non comparable. Perhaps my understanding is just flawed, it wouldn't be the first time. Personally, I'd still rather see the warning get set when NaNs are around. That's colored by my usage patterns where if a NaN is present, it's a problem and I'd like to know about sooner rather than later. -- . __ . |-\ . . tim.hochberg@ieee.org
Timothy Hochberg wrote:
On 7/18/07, *Robert Kern* <robert.kern@gmail.com <mailto:robert.kern@gmail.com>> wrote:
Timothy Hochberg wrote:
> The time is one issue. Another is that ignoring NaNs is only correct if > you are treating NaNs as missing values. If instead you are treating > them as non numbers, the results of some bogus computation, then raising > an error is a more appropriate response. If one was going to take the > time to check for NaNs, one strategy that I would probably support would > be to ignore the NaNs, but set the invalid flag. If the error state for > invalid was set to ignore, then this would work as the missing value > camp likes, otherwise it would raise an error or signal a warning.
I'd almost be willing to make max() and min() always ignore quiet NaNs. The C99 standard requires this, for example, (c.f. section F.9.9.2 of the C99 standard).
Wow! It sure does. That surprises me as it seems antithetical to my understanding of the concept of NaNs being non comparable. Perhaps my understanding is just flawed, it wouldn't be the first time. Personally, I'd still rather see the warning get set when NaNs are around. That's colored by my usage patterns where if a NaN is present, it's a problem and I'd like to know about sooner rather than later.
Well, the IEEE-754 standard is silent, to my reading, on "min" and "max". It's also silent on what wily programmers can do with isnan(), and that's essentially what the C99 standard is specifying: using isnan() to special-case the result of fmin() and fmax(). The operations that IEEE-754 specifies (> and <) are just not being used in the presence of NaNs. Of course, if C99 is free to do whatever the hell they want, so are we. :-) -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
participants (5)
-
David Cournapeau -
Keith Goodman -
Matthieu Brucher -
Robert Kern -
Timothy Hochberg