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

[Charles R Harris]

On Mon, Sep 29, 2008 at 10:50 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Mon, Sep 29, 2008 at 23:02, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Mon, Sep 29, 2008 at 9:02 PM, David Cournapeau
> > <david at ar.media.kyoto-u.ac.jp> wrote:
> >>
> >> Charles R Harris wrote:
> >> >
> >> > So the proposition is, sign, max, min return nan when any of the
> >> > arguments is nan.
> >>
> >> Note that internally, signbit (the C function) returns an integer.
> >
> > That is the signature of the ufunc. It could be changed... I believe the
> > actual signbit of nan is undefined but I suppose we could return -1 in
> the
> > nan case. That would be a fairly typical error signal for integers.
>
> numpy.signbit() should work like C99 signbit() (where possible), IMO.
> It can only return (integer) 0 or 1, and it does differentiate between
> NAN and -NAN. I don't think we should invent new semantics if we can
> avoid it. I think we can change what the platform provides, but only
> in the direction of C99, IMO. I see signbit() as more along the lines
> of functions like isnan() than log().
>

Sounds reasonable.


>
> There is no C99 cognate for numpy.sign(), and it is a float->float
> function, so I think we could make it return NAN. C99's copysign(x,y)
> is almost a cognate (e.g. numpy.sign(y) == copysign(1.0,y) except for
> y==+/-0.0), but since it does fall down on y==0, I don't think it's
> determinative for y==NAN.
>

Sign doesn't distinguish +/-0 . The sign bit of 0 is explicitly cleared in
the current (and former) code by adding +0 to the result.


>
> [~]$ man copysign
> COPYSIGN(3)              BSD Library Functions Manual
>  COPYSIGN(3)
>
> NAME
>     copysign -- changes the sign of x to that of y
>
> SYNOPSIS
>     #include <math.h>
>
>     double
>     copysign(double x, double y);
> ...
> [~]$ gcc --version
> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> [~]$ cat foo.c
> #include <stdio.h>
> #include <math.h>
>
> int main(int argc, char **argv)
> {
>    printf("signbit(NAN) = %d\n", signbit(NAN));
>    printf("signbit(-NAN) = %d\n", signbit(-NAN));
>    printf("copysign(1.0, NAN) = %g\n", copysign(1.0, NAN));
>    printf("copysign(1.0, -NAN) = %g\n", copysign(1.0, -NAN));
>    return 0;
> }
> [~]$ gcc -std=c99 -o foo foo.c -lm
> [~]$ ./foo
> signbit(NAN) = 0
> signbit(-NAN) = 1
> copysign(1.0, NAN) = 1
> copysign(1.0, -NAN) = -1
>

Hmm,

signbit(NAN) = 0
signbit(-NAN) = -2147483648
copysign(1.0, NAN) = 1
copysign(1.0, -NAN) = -1
signbit(0.0) = 0
signbit(-0.0) = -2147483648
copysign(1.0, 0.0) = 1
copysign(1.0, -0.0) = -1

Looking at the standard, signbit is only required to return a non-zero value
for negatives. I think we need to be more explicit for numpy. How about 1?

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