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

[Dan Bishop]

On Mar 11, 9:31 am, "Mark Dickinson" <dicki...@gmail .comwrote:

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.

IIRC, float.__repr__ just does whatever libc does. Have you tried
using printf("%g, %g", 0.0, -0.0) in a C program?

[jim-on-linux]

On Sunday 11 March 2007 10:31, Mark Dickinson
wrote:

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

This works for some reason
instead of x,y = -0.0, 0.0
clumpy but the results are right.

x = -0.0
y= 0.0

x,y
(-0.0, 0.0)


jim-on-linux
http:\\inqvista .com

[Terry Reedy]

"Dan Bishop" <da*****@yahoo. comwrote in message
news:11******** *************@3 0g2000cwc.googl egroups.com...
| On Mar 11, 9:31 am, "Mark Dickinson" <dicki...@gmail .comwrote:
| 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)
|| IIRC, float.__repr__ just does whatever libc does. Have you tried
| using printf("%g, %g", 0.0, -0.0) in a C program?

Detailed FP behavior like this is system (and yes, libc) dependent. On
WinXP
IDLE 1.1.3

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

(0.0, 0.0)

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

(0.0, 0.0)

>>-0.0

0.0

Terry Jan Reedy

[Mark Dickinson]

On Mar 11, 12:13 pm, "Terry Reedy" <tjre...@udel.e duwrote:

"Dan Bishop" <danb...@yahoo. comwrote in message

news:11******** *************@3 0g2000cwc.googl egroups.com...
| On Mar 11, 9:31 am, "Mark Dickinson" <dicki...@gmail .comwrote:
| 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)
|| IIRC, float.__repr__ just does whatever libc does. Have you tried
| using printf("%g, %g", 0.0, -0.0) in a C program?

Detailed FP behavior like this is system (and yes, libc) dependent. On
WinXP
IDLE 1.1.3>>x,y = 0.0, -0.0

>x,y

(0.0, 0.0)

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

(0.0, 0.0)

>-0.0

0.0

Terry Jan Reedy

Interesting. So on Windows there's probably no hope of what I want to
do working.
But on a platform where the C library does the right thing with signed
zeros, this
behaviour is still a little surprising. I guess what's happening is
that there's
some optimization that avoids creating two separate float objects for
a float literal
that appears twice, and that optimization doesn't see the difference
between 0. and -0.

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

True

jim-on-linux's solution works in the interpreter, but not in a script,
presumably because we've got file-wide optimization rather than
line-by-line optimization.

#test.py
x = -0.0
y = 0.0
print x, y
#end test.py

>>import test

-0.0 -0.0

Mark

[Duncan Booth]

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

I guess what's happening is that there's some optimization that avoids
creating two separate float objects for a float literal that appears
twice, and that optimization doesn't see the difference between 0. and
-0.

Don't guess. Test.

>>def f():

x = 0.0
y = -0.0
return x, y

>>dis.dis(f)

2 0 LOAD_CONST 1 (0.0)
3 STORE_FAST 0 (x)

3 6 LOAD_CONST 1 (0.0)
9 STORE_FAST 1 (y)

4 12 LOAD_FAST 0 (x)
15 LOAD_FAST 1 (y)
18 BUILD_TUPLE 2
21 RETURN_VALUE

Yes. Just the one constant there.
Tim Peters wrote in
http://blog.gmane.org/gmane.comp.pyt.../day=20050409:

All Python behavior in the presence of a NaN, infinity, or signed zero
is a platform-dependent accident. This is because C89 has no such
concepts, and Python is written to the C89 standard. It's not easy to
fix across all platforms (because there is no portable way to do so in
standard C), although it may be reasonably easy to fix if all anyone
cares about is gcc and MSVC (every platform C compiler has its own set
of gimmicks for "dealing with" these things).

[Alex Martelli]

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

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.

Looks to me like you've found a bug with the parser/compiler:

>>c=compile('-0.0,0.0', 'eval', 'eval')
eval(c)

(-0.0, -0.0)

>>dis.dis(c)

1 0 LOAD_CONST 1 ((-0.0, -0.0))
3 RETURN_VALUE

Similar problems appear in parsing display forms of lists and dicts and
calls to functions with constant arguments (among which a constant 0.0
and a constant -0.0) -- and more generally when both constants -0.0 and
0.0 appear within the same "unit of compilation" (expression, function,
....) as for example in:

>>def f():

.... a = -0.0
.... return a, 0.0
....

>>f()

(-0.0, -0.0)

>>>

Why I think it has specifically to do with parsing/compiling, e.g.:

>>{23:-0.0, 45:0.0}

{45: -0.0, 23: -0.0}

>>x=0.0
y=-0.0
{23:x, 45:y}

{45: -0.0, 23: 0.0}

>>>

so there appears to be no problem once the 0.0 and -0.0 values come from
variables or the like -- only if they're both from constants within the
same "unit of compilation". Indeed, if you put the code above in a
function, rather than in separate entries to the toplevel
interpreter...:

>>def g():

.... x = 0.0
.... y = -0.0
.... return {23:x, 45:y}
....

>>g()

{45: 0.0, 23: 0.0}

>>>

....the bug surfaces again. Looks a bit like the result of a slightly
errant "peephole optimizer" pass which tries to roll multiple
occurrences of "the same constant" within the same codeobject into a
single one, and consider two immutables a "multiple occurrence" if
they're == to each other (as, indeed, 0.0 and -0.0 must be).

The Python-coded compiler package does NOT give the problem:

>>compiler.comp ile('-0.0,0.0','zap', 'eval')

<code object <expressionat 0x70068, file "zap", line 1>

>>dis.dis(_)

1 0 LOAD_CONST 1 (0.0)
3 UNARY_NEGATIVE
4 LOAD_CONST 1 (0.0)
7 BUILD_TUPLE 2
10 RETURN_VALUE

....presumably because it doesn't do peephole optimization (nor any other
kind of optimization).

Unfortunately I've never really looked in depth into these parts of
Python so I can't help much; however, if you open a bug at
<http://sourceforge.net/tracker/?group_id=5470I think you stand a good
chance of eventually seeing it fixed in 2.5.x for some x.
Python/peephole.c does appear to be taking some care in constant
folding:

192 case UNARY_NEGATIVE:
193 /* Preserve the sign of -0.0 */
194 if (PyObject_IsTru e(v) == 1)
195 newconst = PyNumber_Negati ve(v);

so I suspect the problem is elsewhere, but I can't find it yet.
Alex
In the meantime, I hope that some available workarounds for the bug are
clear from this discussion: avoid using multiple constants in a single
compilation unit where one is 0.0 and another is -0.0, or, if you really
can't avoid that, perhaps use compiler.compil e to explicitly build the
bytecode you need.

[Mark Dickinson]

On Mar 11, 1:21 pm, Duncan Booth <duncan.bo...@i nvalid.invalidw rote:

Tim Peters wrote inhttp://blog.gmane.org/gmane.comp.pyth on.devel/day=20050409:

All Python behavior in the presence of a NaN, infinity, or signed zero
is a platform-dependent accident. This is because C89 has no such
concepts, and Python is written to the C89 standard. It's not easy to
fix across all platforms (because there is no portable way to do so in
standard C), although it may be reasonably easy to fix if all anyone
cares about is gcc and MSVC (every platform C compiler has its own set
of gimmicks for "dealing with" these things).

Understood. Platform dependent is fine. But does this really excuse
results
like the following?

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

-3.14159265359

>>print atan2(0., -1.)

3.14159265359

Mark

[Alex Martelli]

Duncan Booth <du**********@i nvalid.invalidw rote:

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

I guess what's happening is that there's some optimization that avoids
creating two separate float objects for a float literal that appears
twice, and that optimization doesn't see the difference between 0. and
-0.

Don't guess. Test.

>def f():

x = 0.0
y = -0.0
return x, y

>dis.dis(f)

2 0 LOAD_CONST 1 (0.0)
3 STORE_FAST 0 (x)

3 6 LOAD_CONST 1 (0.0)
9 STORE_FAST 1 (y)

4 12 LOAD_FAST 0 (x)
15 LOAD_FAST 1 (y)
18 BUILD_TUPLE 2
21 RETURN_VALUE

Yes. Just the one constant there.

And yet, as I wrote in a parallel post (the result of quite some
exploration), Python/peephole.c takes specific precautions against
improperly "constant folding" for the unary-minus of 0.0 -- the
collapsing of 0.0 and -0.0 into the "same" constant must happen
elsewhere (I haven't found out where, yet) and doesn't happen in the
Python-coded compiler module. So (on platforms where the underlying C
libraries do the right thing) I think this specific "overzealou s
constant folding" must be considered a small bug -- and should be easy
to fix (by specialcasing -0.0 like Python/peephole.c does) if I could
but find out where in the Python sources the folding is happening...
Alex

[Mark Dickinson]

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

[Long analysis of probable cause of the problem]

Thank you for this. I was suspecting something along these lines,
but I don't yet know my way around the source well enough to figure
out where the problem was coming from.

In the meantime, I hope that some available workarounds for the bug are
clear from this discussion: avoid using multiple constants in a single
compilation unit where one is 0.0 and another is -0.0, or, if you really
can't avoid that, perhaps use compiler.compil e to explicitly build the
bytecode you need.

Yup: the workaround seems to be as simple as replacing all occurrences
of -0.0 with -(0.0). I'm embarrassed that I didn't figure this out
sooner.

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

(-0.0, 0.0)

Mark