Signed zeros: is this a bug?

[Mark Dickinson]

I get the following behaviour on Python 2.5 (OS X 10.4.8 on PowerPC,
in case it's relevant.)

>>x, y = 0.0, -0.0
x, y

(0.0, 0.0)

>>x, y = -0.0, 0.0
x, y

(-0.0, -0.0)

I would have expected y to be -0.0 in the first case, and 0.0 in the
second. Should the above be considered a bug, or is Python not
expected to honour signs of zeros? I'm working in a situation
involving complex arithmetic where branch cuts, and hence signed
zeros, are important, and it would be handy if the above code could be
relied upon to do the right thing.

Mark

[Paul Rubin]

"Mark Dickinson" <di******@gmail .comwrites:

By the way, I don't suppose that anybody would be interested in
a rewritten cmath for Python 2.6? It wouldn't be hard for me to
rewrite what I already have in C, and add suitable documentation
and tests.

I can't speak for the developers but my personal opinion is that this
is worthwhile. I'm pretty Common Lisp and Scheme specify the branch
cuts and I believe Java does the same. That is to help with the
consistency and predicability of program behavior as well as to help
various numerical algorithms. C has a different goal, which is to be
a semi-portable assembly language, putting priority instead on
minimizing intermediation between the programmer and the machine,
instead of on predicability. Python should take the approach of the
higher level languages and implement this stuff precisely, instead of
just going along with whatever loose semantics the underlying C
implementation happens to supply.

[Paddy]

On Mar 11, 9:28 pm, Paul Rubin <http://phr...@NOSPAM.i nvalidwrote:

Dennis Lee Bieber <[e-mail] com.comwrites:

Pardon? What is "the right thing with signed zeros"... In the last
30 years I've been on machines that normalize floating zero into a true
zero (all bits are zero: mantissa, exponent, and sign). This is the
first time I've even seen a variable output as a negative 0.0!

Most machines these days use IEEE 754 which supports negative zero.

http://en.wikipedia.org/wiki/Negative_zero

Isn't negative zero mathematically the same as zero? Isn't -0 just an
artefact of the representation of floating point numbers? Shouldn't
f(0) == f(-0) for all functions f?
I read the wikipedia article about meteorologists using -0 to denote a
negative number rounded to zero for the purposes of binning, i.e. if
you want to tally days with temperature above and below zero, but it
doesn't seem right. You should arrange for any temperature to be in
only one range and record temperatures to their determined accuracy. a
temperature of zero would only be in one bin and if a temperature is
read as -0.2 and th rounding says it should be taken as zero then it
should go in the same bin as any positive reading that is rounded to
zero.
Getting back to Python, shouldn't we strive to remove any distinction?
a zero is a zero regardless of sign and a function like atan returning
one of two different vaues for an argument of zero is actually
mathematically not a bad thing to do?

- Paddy.

[Michael Spencer]

Gabriel Genellina wrote:

>
(I cannot find peephole.c on the source distribution for Python 2.5, but
you menctioned it on a previous message, and the comment above refers to
the peephole optimizer... where is it?)

The peephole optimizer is in compile.c - the entry point is optimize_code

BTW, I have written a pure-Python compiler which aims to be functionally
identical to the Python 2.5 compiler, and is in fact very similar (much closer
than stdlib.compiler ). It may be helpful in investigating alternative
workarounds for the -0.0 issue.

http://svn.brownspencer.com/pycompil...nches/new_ast/

Michael

[Paul Rubin]

"Paddy" <pa*******@goog lemail.comwrite s:

Most machines these days use IEEE 754 which supports negative zero.
http://en.wikipedia.org/wiki/Negative_zero

Isn't negative zero mathematically the same as zero? Isn't -0 just an
artefact of the representation of floating point numbers? Shouldn't
f(0) == f(-0) for all functions f?

Not sure what you mean. "Floating point numbers" and in particular
"IEEE 754 floating point numbers" are a set of values and operations
with particular characteristics , that computers happen to implement.
They are not the same thing as the mathematical real numbers. For
example, there are infinitely many real numbers, but there are only
finitely many 64-bit IEEE floating point numbers (at most 2**64 of
them). They don't satisfy the same algebraic laws as real numbers.
For example, (1e100 + 1) == 1e100, and as a consequence, (1e100 + 1) -
1e100 == 0, but (1e100 - 1e100) + 1 == 1, so the commutative addition
law doesn't hold. These are all part of a mesh of interlocking
compromises made in floating point computer arithmetic to approximate
real-number arithmetic with finite-precision values. At first (i.e.
from the early computer era through the 1970's or so) this stuff was
designed somewhat ad hoc by computer architects, but eventually
serious numerical mathemticians got into the act, figuring out how to
make the best possible choices of these compromises for numerical
computation. The result was IEEE 754, which resulted in Prof. Kahan
winning the Turing award in 1989.

IEEE 754 specifies that -0 and +0 are separate numbers. Yes it is an
artifact in the sense of being one of the compromises. But these
compromises all interact with each other to make the errors cancel in
various numerical algorithms. The existence of -0 in IEEE 754 is part
of an intricate framework designed very carefully over a long period
by extremely experienced and knowledgeable people who knew what they
were doing. It's not really wise to mess with it unless you're
planning to undertake a project to redesign computer arithmetic of
similar scope to the IEEE 754 effort.

Getting back to Python, shouldn't we strive to remove any distinction?
a zero is a zero regardless of sign and a function like atan returning
one of two different vaues for an argument of zero is actually
mathematically not a bad thing to do?

No. Floating point numbers are not the same as real numbers and they
don't satisfy the same laws. There have been some proposals
(rejected) for Python to support exact rational arithmetic in addition
to floating point and exact integer arithmetic. Exact rationals in
Python (if implemented) should behave like mathematical rationals.
But Python floating point arithmetic should follow IEEE 754, at least
when the hardware supports it, which these days is almost always.

[=?iso-8859-1?B?QW5kcuk=?=]

On Mar 11, 7:49 pm, "Paddy" <paddy3...@goog lemail.comwrote :

>
Isn't negative zero mathematically the same as zero? Isn't -0 just an
artefact of the representation of floating point numbers? Shouldn't
f(0) == f(-0) for all functions f?

Read the original post again... The relevant part is:
====
I'm working in a situation
involving complex arithmetic where branch cuts, and hence signed
zeros, are important, and it would be handy if the above code could be
relied upon to do the right thing.
====

You may want to read about branch cuts and complex arithmetics. I
don't mean this as a putdown - simply as a useful suggestion for you
to read.

André

[Alex Martelli]

Gabriel Genellina <ga*******@yaho o.com.arwrote:

En Sun, 11 Mar 2007 15:26:01 -0300, Alex Martelli <al***@mac.come scribió:

Or maybe we should give up ever storing -0.0 in the tables
of constant and ALWAYS have "0.0, unary-minus" wherever it appears (that
would presumably require working on the AST-to-bytecode visitors that
currently work ever-so-slightly-differently for this specific
troublespot in the C-coded version vs the Python-coded one...).

I think that way is the less intrusive, doesn't rely on a particular FP
implementation, and the more likely to be accepted.
Looking at ast.c, the culprit is some optimization in ast_for_factor, line
1506
/* If the unary - operator is applied to a constant, don't generate
a UNARY_NEGATIVE opcode. Just store the approriate value as a
constant. The peephole optimizer already does something like
this but it doesn't handle the case where the constant is
(sys.maxint - 1). In that case, we want a PyIntObject, not a
PyLongObject.
*/

After the long "if", I would use parsenumber(STR (pnum)) and check the type
and value of the resulting object; if it's a float and 0.0, skip the
optimization and continue below as a normal case.
Unfortunately I'm not able to compile and test the code right now, so I
can't provide an actual patch. (At least, not until tuesday). But I hope
this simple comment is useful anyway...

Yep, it sure might, if I can make time to act on it:-).

(I cannot find peephole.c on the source distribution for Python 2.5, but
you menctioned it on a previous message, and the comment above refers to
the peephole optimizer... where is it?)

http://svn.python.org/view/python/tr...rev=54086&view
=auto

to browse the current version on the trunk. Right under the Python
toplevel subdirectory in the sources, IOW.
Alex

[Alex Martelli]

Alex Martelli <al***@mac.comw rote:
...

Yep, it sure might, if I can make time to act on it:-).

....and I did -- patch 1678668 is right there, brand newm at
<http://sourceforge.net/tracker/index.php.

I hope it also satisfies the timbot's very reasonable lament about the
bug resurfacing once in a while, since it included one more unittest to
check whether the bug is there (TDD rocks!-).
Alex

[Alex Martelli]

Tim Peters <ti*****@comcas t.netwrote:
...

It's a bug that keeps resurfacing, probably because there's no portable
way to test that it stays fixed :-( (it's not an accident that the OP
relied on atan2 to distinguish +0.0 from -0.0! they act the same in

Please take a look at my patch 1678668, brand new at
<http://sourceforge.net/tracker/index.phpand as yet unassigned (hint,
hint:-).

I hope it satisfies your very reasonable lament about the bug
resurfacing once in a while, since it included one more unittest to
check whether the bug is there (TDD rocks!-), based exactly on the
behavior of atan2 (only on IEEE-format machines, though).

2.5 introduced a new front end and more ambitious constant-folding, and
I expect the bug showed up again due to one of those.

Yep, in ast.c's ast_for_factor -- it lacks the specialcasing that
peephole.c does have (and my patch essentially adds it back).

If it's worth specialcasing in peephole.c (and I strongly agree with
Raymond's implicit opinion that it is), it should be just as worth
specialcasing in ast.c, no?-)
Alex

[Alex Martelli]

Mark Dickinson <di******@gmail .comwrote:

On Mar 11, 2:59 pm, [e-mail] (Alex Martelli) wrote:

[...]
OTOH, Python 2.4 works just fine...:

Python 2.4.3 (#1, Apr 7 2006, 10:54:33) [GCC 4.0.1 (Apple Computer,
Inc. build 5250)] on darwin Type "help", "copyright" , "credits" or
"license" for more information.>>0 .0,-0.0
(0.0, -0.0)

>>-0.0,0.0

(-0.0, 0.0)

so it seems to be very specifically a 2.5 problem.

I've filed a bug report (bug #1678380) and got an impressively
quick response from MvL. It looks like this is a `won't fix'.
Oh well.

That bug isn't formally closed yet, and the discussion's going on, we'll
see. Meanwhile can you try my patch 1678668 just to double check it
does fix everything? (It's agains the current HEAD of Python's svn).
Alex

[Alex Martelli]

Paul Rubin <http://ph****@NOSPAM.i nvalidwrote:

(rejected) for Python to support exact rational arithmetic in addition
to floating point and exact integer arithmetic. Exact rationals in
Python (if implemented) should behave like mathematical rationals.
But Python floating point arithmetic should follow IEEE 754, at least
when the hardware supports it, which these days is almost always.

Incidentally (and I know you know that, Paul, but others interested in
this thread might not) fast exact rational arithmetic (based on the LGPL
library named GMP) is supplied, among other functionality, by module
gmpy, currently found at http://code.google.com/p/gmpy/ (this version is
more recent than the older one at sourceforce, which for some reason
doesn't let me update things right any more).
Alex