On Mon, Sep 29, 2008 at 10:50 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 29, 2008 at 23:02, Charles R Harris > <[EMAIL PROTECTED]> wrote: > > > > > > On Mon, Sep 29, 2008 at 9:02 PM, David Cournapeau > > <[EMAIL PROTECTED]> 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
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion