[Numpy-discussion] nan, sign, and all that

David Cournapeau cournape@gmail....
Thu Oct 2 03:23:59 CDT 2008


On Thu, Oct 2, 2008 at 4:37 PM, Stéfan van der Walt <stefan@sun.ac.za> wrote:
>
> These are great, many thanks!
>
> My only gripe is that they have the same NaN-handling as amin and
> friends, which I consider to be broken.  Others also mentioned that
> this should be changed, and I think David C wrote a patch for it (but
> I am not informed as to the speed implications).

Hopefully, Chuck and me synchronised a bit on this :) The idea is that
before, I thought that there was a nan ignoring and nan propagating
behavior. Robert later mentioned that fmin/fmax has a third, well
specified behavior in C99. All those three are useful, and as such
have been more or less implemented by Chuck or me.

I think having the new C functions by Chuck makes sense as a new
python API, to follow C99 fmax/fmin. They could be used for the new
max/min, but then, it feels it a bit strange compared to
nanmax/nanmin, so I would prefer having the *current* numpy.max and
numpy.min propagate the NaN, and nanmax/nanmin ignoring the NaN
altogether.

Also note that matlab does not propagate NaN for max/min.

The last question is FPU status flag handling: I thought comparing NaN
directly with < would throw a FPE_INVALID. But this is not the case
(at least on Linux with glibc and Mac OS X). This is confusing because
I thought the whole point of C99 macro isgreater was to not throw
this. This is also how I understand both glibc manual and mac os x man
isgreater. Robert, do you have any insight on this ?

David


More information about the Numpy-discussion mailing list