[Numpy-discussion] What is the sign of nan?

[Charles R Harris]

On Mon, Sep 29, 2008 at 10:09 PM, David Cournapeau <
david at ar.media.kyoto-u.ac.jp> wrote:

> Charles R Harris wrote:
> >
> > Yes, that too. But I was thinking of the ufunc returning nan when needed
>



>
>
> I think this is better for consistency, yes. NaN is not a number, so it
> has no sign :) More seriously, I think those features should be clearly
> listed and thought out before being implemented, particularly wrt error
> handling and testing. I would rather see umathmodule.c cleaning first,


umathmodule.c is cleaned/done. Or was until I put in some of the nan
handling. But some of the nan comparisons were just odd, in particular the
sign function, which was effectively undefined. And since the current
behavior is an accident of comparison choices and order, I consider it
undefined also. So at a minimum I would fix up sign/maximum/minimum. That
would be consistent with both masking and error propagation in common usage.
The curiosities arise when using the reduce method. Also returning -1 for
the signbit seems like the right thing to do. If the nan comparisons can't
be relied on, then using the isnan macro is an option. However, I am not
inclined to go on and use isfinite and all those.


> wo any functionality change, and then, once integrated in the trunk, do
> the NaN changes in a branch, in particular because of broken
> implementations which will not do what you expect. Personally, I also
> have changes for NaN handling, but on my private git import of numpy.
>

I'm am currently working off your branch (at your suggestion). Is it safe to
use NAN?


> Also, if we fix this, we should fix this once for all, and with a lot of
> tests, if only to test on buggy implementations.
>

Yes, the tests will define the standard. There is one test for sign of
complex numbers that currently breaks, but I don't consider that important
as anyone currently relying on sign when the array contains nans is out of
their mind. An option for making the code more portable is to make the
various comparison operators macros, then worry about fixing the macros for
various compilers. I would be happy to use macros such as lessthan, which in
addition to other things are not supposed to raise exceptions. Of course, if
MS compilers don't even get the arithmetic right...

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080929/49750a5d/attachment.html>