Duncan Booth <[EMAIL PROTECTED]> wrote: > "Mark Dickinson" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
