Signed zeros: is this a bug?

[Alex Martelli]

Duncan Booth <duncan.booth at invalid.invalid> wrote:

> "Mark Dickinson" <dickinsm at gmail.com> wrote:
> 
> > 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 "overzealous
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