The identification of -0.0 and 0.0 in scripts leads to some surprising
results.  In particular, code that behaves one way in the interpreter can behave differently in a script.  For example:

Python 2.6a0 (trunk:54183M, Mar  6 2007, 20:16:00) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import atan2;
>>> x = -0.
>>> y = 0.
>>> print atan2(y, -1.)
3.14159265359

But:

>>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y, -1.)")
-3.14159265359

A simpler example:

>>> x, y = -0., 0.
>>> x, y
(-0.0, -0.0)
>>> id(x) == id(y)
True

But:

>>> x = -0.
>>> y = 0.
>>> x, y
(-0.0, 0.0)

This occurs both on SuSE Linux 9.3/i686 and on OS X 10.4.8/PowerPC.

This is not a bug, at least not one that will be fixed. Details of the floating-point can vary across platforms, and they may behave in suprising ways in various contexts. Users shouldn't rely on Python differentiating between -0 and +0.

May I beg for reconsideration.
Is the following really considered acceptable?

>>> x = -0.; atan2(0., -1)
-3.1415926535897931
>>> x = -(0.); atan2(0., -1)
3.1415926535897931
>>> atan2(0., -1)
3.1415926535897931

A single x = -0. at the start of a script can have
side effects several hundred lines later, even when
the variable x is never referred to again.  I guess
the advice should be:  "To avoid surprises, -0. should
never appear in any script."

It appears to be a problem in the way compile.c handles literals.
See http://mail.python.org/pipermail/python-list/2007-March/430302.html

marketdickinson, you should ask this question (is this really acceptable) on python-dev. I find it perfectly acceptable. No program should rely on -0 and +0 being two different things (and thus also not relying on atan2 giving two different results).

I expressed myself badly.  I apologise.  This really isn't about +0. and -0. 
being different, or not.  I'm perfectly comfortable with the idea that +0. 
and -0. may or may not be distinguishable on any given platform.

The surprise is the other way around: two *identical* calls to atan(0., -1.)
(or to repr(0.) for that matter) give *different* results, depending solely 
on whether a -0. literal has appeared earlier on in the code unit being compiled.

So if the first float zero literal encountered in a source file just happens to be a
-0. rather than a 0., the meaning of str(0.) later on suddenly becomes "-0.0"
rather than "0.0".  I'd like to be able to rely on str(0.) meaning "0.0" without
having to worry about whether there might be a -0. literal appearing in some
faraway and otherwise completely irrelevant portion of the file.

Also see my patch 1678380 which fixes this bug (and checks for it in a new unittest).

Oops,sorry, I meant patch 1678668 (copy-and-pasted the wrong ID:-).

Alex

I also expressed myself badly. I not only meant that programs should not rely on +0 and -0 being different things across platforms, but that they should also not rely on them being either always different or always the same in a single program. If Python would randomly chose to interpret +0 as -0, or would do so for every third occurence, I still couldn't see a problem.

and yet, peephole.c does specialcase -0 (with a comment and all!-) avoiding constant-folding optimization for it -- making things work fine in Python 2.4.x for high enough x -- it's just that peephole.c's efforts are defeated by a similar optimization applied without specialcase checking in ast.c in Python 2.5.  This is inconsistent: it makes no sense to take SOME of the precautions needed to avoid an issue but not ALL of them, since this makes the issue appear anyway, so those precautions that ARE taken are there for no purpose (except a miniscule slowdown and enlargement of the interpreter:-).  Either we save those few lines of code in peephole.c or add the few lines to ast.c that I suggest in my patch 1678668 -- the current situation makes no sense.

The distinction between +0.0 and -0.0 was important to Tim for get the branch cuts to work correctly.  That was the reason for the special-casing in earlier versions in pre-ast versions of compile.c and in the peephole optimizer.

Alex's patch looks correct.  It should go into Py2.5.1.

It's fixed in 2.6 but still broken in 2.5.

This was fixed in the trunk in revision 57284.  I've backported the fix to Python 2.5.2 in revision 
60183.

Leaving this open because there's still a problem for complex numbers, though I guess this is less 
likely to bite people:

Python 2.6a0 (trunk:60158M, Jan 21 2008, 16:21:41) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 0j
0j
>>> -0j
-0j
>>> [0j, -0j]
[0j, 0j]

Here's a patch, against the trunk, that imitates Alex's fix for the complex case.

Bug identifying 0j and -0j fixed for Python 2.6 in revision 60483.

Martin, can this be backported to 2.5.2?  I'll assume not, unless I hear
otherwise from you.

Closing.

This bug is still present on arm. 

Python 2.6.3 

cs-e9302# cat ../prova.py
import  math
print math.atan2(0., -0.)
print (math.copysign(4., -0.), -4.0)
print math.atan2(0., -0.)
print (math.copysign(4., -0.), -4.0)
print math.atan2(0., -0.)

cs-e9302# cat ../prova1.py
import  math
print (math.copysign(4., -0.), -4.0)
print math.atan2(0., -0.)
print (math.copysign(4., -0.), -4.0)
print math.atan2(0., -0.)

cs-e9302# ./python ../prova1.py
(-4.0, -4.0)
-3.14159265359
(-4.0, -4.0)
-3.14159265359
cs-e9302# ./python ../prova.py
0.0
(4.0, -4.0)
0.0
(4.0, -4.0)
0.0




>>> from math import atan2
>>> x = -0.
>>> y = 0.
>>> print atan2(y, -1.)
3.14159265359
>>> exec("from math import atan2; x = -0.; y = 0.; print atan2(y,
-1.)")
-3.14159265359
>>> x = -0.; atan2(0., -1)
-3.1415926535897931
>>> x = 0.; atan2(0., -1)
3.1415926535897931

======================================================================
FAIL: testAtan2 (__main__.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_math.py", line 131, in testAtan2
    self.ftest('atan2(0., -0.)', math.atan2(0., -0.), math.pi)
  File "Lib/test/test_math.py", line 57, in ftest
    (name, value, expected))
AssertionError: atan2(0., -0.) returned 0.0, expected
3.1415926535897931

======================================================================
FAIL: testCopysign (__main__.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_math.py", line 806, in testCopysign
    self.assertEqual(math.copysign(4., -0.), -4.0)
AssertionError: 4.0 != -4.0

----------------------------------------------------------------------

Mancausoft:  is this little-endian, OABI?

If so, then I think I know  what the problem is:  the disambiguation code 
in compile.c looks at the first and last bytes of the double to 
distinguish 0.0 and -0.0;  for mixed-endian (aka little-endian, swapped 
words) doubles this will fail.

The solution is to use copysign instead.

Mark Dickinson <report@bugs.python.org> scrisse:

> Mancausoft:  is this little-endian, OABI?

Mixed endian

> If so, then I think I know  what the problem is:  the disambiguation
> code in compile.c looks at the first and last bytes of the double to 
> distinguish 0.0 and -0.0;  for mixed-endian (aka little-endian,
> swapped words) doubles this will fail.
> 
> The solution is to use copysign instead.

I try: *p==0 && p[sizeof(double)-1]==0 && p[(sizeof(double)-1)/2]==0;

and now the test_math result is:

Ran 39 tests in 21.323s

OK        

It's a safe patch?

Mancausoft

> I try: *p==0 && p[sizeof(double)-1]==0 && p[(sizeof(double)-1)/2]==0;

Sure, that should work.  It would seem cleaner and safer to use copysign, 
though: that way, things will still work when some other byte layout comes 
along, or when some version of Python starts using 128-bit IEEE 754 
doubles instead of 64-bit, or ...

Reopening:  I've been meaning to fix these checks to use copysign for a 
while now, anyway.

Here's a patch for floats.  Mancausoft, could you give this a try and let 
me know whether it fixes the issue?

The same fix would also need to be applied for complex numbers.

Mark Dickinson <report@bugs.python.org> scrisse:

> 
> Mark Dickinson <dickinsm@gmail.com> added the comment:
> 
> Here's a patch for floats.  Mancausoft, could you give this a try and
> let me know whether it fixes the issue?

it works.

test_math

Ran 39 tests in 23.561s                                               

OK

test_float
Ran 19 tests in 275.241s

OK

Mancausoft

Thanks for testing!  I'll apply the fix once the 2.6 branch is unfrozen.

Applied (along with a corresponding fix for the complex type) in
revisions r76575 through r76578.