Re: Signed zeros: is this a bug?

On Mar 11, 12:13 pm, "Terry Reedy" <tjre...@xxxxxxxx> wrote:
"Dan Bishop" <danb...@xxxxxxxxx> wrote in message

news:1173629090.993914.55570@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
| On Mar 11, 9:31 am, "Mark Dickinson" <dicki...@xxxxxxxxx> 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)
|| 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

.

Quantcast