On Mar 11, 12:13 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > "Dan Bishop" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > | On Mar 11, 9:31 am, "Mark Dickinson" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
