Author christian.heimes
Recipients Rhamphoryncus, christian.heimes, gvanrossum, mark.dickinson
Date 2008-01-03.16:57:45
SpamBayes Score 0.0010692
Marked as misclassified No
Message-id <477D1407.4070006@cheimes.de>
In-reply-to <1199319060.95.0.0776451148099.issue1640@psf.upfronthosting.co.za>
Content
Guido van Rossum wrote:
> Guido van Rossum added the comment:
> 
> One nit: you added a blank line to the end of test_math.py.
> This will cause the checkin to fail. :-)

*grr* stupid white space check hook

> One bigger issue: the sign() function doesn't seem to work properly for
> nans.  E.g. on Linux I get:
> 
>>>> inf = 1e1000
>>>> nan = inf/inf
>>>> mnan = -nan
>>>> math.sign(nan)
> -1
>>>> math.sign(mnan)
> 1
> 
> IOW a positive nan is considered negative and vice versa.  (This is
> probably due to the way nans defy testing, always returning false.)

If I recall the definition correctly NaNs don't have a sign. The content
of the sign bit is not defined for NaNs. I could fix the sign but it's
just eye candy and a waste of CPU cycles. IMO it would be more
appropriate to return 0 for NaNs instead of +1 or -1.

> I'm also curious why math.sign(0.0) returns 1 -- this is going to
> cause a lot of confusion.

math.sign(0.0) == 1 and math.sign(-0.0) == -1 is the main purpose of the
sign() function. Most ordinary users are still going to use x > 0.0 or x
< 0.0 instead of math.sign(). math.sign() is for the power users who
need to determinate whether an operation hits the 0 from the left or
right side of the number line.

Because 0.0 == -0.0 it's not possible the distinguish a positive from a
negative zero with comparison operations. if x == 0.0 and
str(x).startswith("-") was the only existing way to detect a negative zero.

Christian
History
Date User Action Args
2008-01-03 16:57:46christian.heimessetspambayes_score: 0.0010692 -> 0.0010692
recipients: + christian.heimes, gvanrossum, mark.dickinson, Rhamphoryncus
2008-01-03 16:57:46christian.heimeslinkissue1640 messages
2008-01-03 16:57:45christian.heimescreate