in reply to Re: Negative zero from a multiplication by a zero?
in thread Negative zero from a multiplication by a zero?

Interesting. I just figured they were getting stored as IVs, but that's not the case. That means you can't work around the problem by upgrading the vars to NVs since they already are!
$ perl -MDevel::Peek -e'$x=-2.1; Dump $x; $x*=0; Dump $x' SV = NV(0x5291b8) at 0x504ca0 REFCNT = 1 FLAGS = (NOK,pNOK) NV = -2.1 SV = PVNV(0x507598) at 0x504ca0 REFCNT = 1 FLAGS = (NOK,pNOK) IV = -2 NV = -0 PV = 0 $ perl -MDevel::Peek -e'$x=-2.0; Dump $x; $x*=0; Dump $x' SV = NV(0x5291b8) at 0x504ca0 REFCNT = 1 FLAGS = (NOK,pNOK) NV = -2 SV = PVNV(0x507598) at 0x504ca0 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 NV = -2 PV = 0

Replies are listed 'Best First'.
Re^3: Negative zero from a multiplication by a zero?
by ysth (Canon) on Jun 12, 2009 at 16:11 UTC
      If you were desperate, you could compile a perl with PERL_PRESERVE_IVUV turned off.

      Hey ... that works!! (No, I'm not desperate - just anal :-)

      Any arithmetic operation on IV's now seems to turn them into NV's so (-2 * 0) reports -0 even though the original operands are IV's.
      (2 * -0) reports 0, but that's to be expected given the underlying events.
      (2 * -0.0) does report -0, again as expected.

      One thing I did find while building this perl was that 'dmake test' reported 2 failures in the Devel::Peek tests - all other tests passed. I suspect those 2 Devel::Peek tests might be overlooking the possibility of NO_PERL_PRESERVE_IVUV being defined. I'll check that out properly later today, and submit a bug report.

      Cheers,
      Rob

        Somebody should just fix the bad floating point implementation / standard. Having -1.2 * 0 be -0 rather seriously misses the point of "negative zero" and brings it into play in places where it has no business and is just a royal pain with no benefit.

        If you want to detect the sign of your underflow, you should bother to check before multiplying by a negative value or you should get a floating point implementation that distinguishes "zero" from "positive zero" (but most floating point implementations don't do that because "negative zero" was partly motivated by having a spare bit handy and there isn't as handy of a bit to make "positive zero" out of).

        Surely we need "negative NaN" as much as "negative zero". We must distinguish +Inf * 0 from +Inf * -0, surely. At least, it makes just as much sense as having "negative zero" for one underflow case (but not having a special value for "positive underflow", much less another for "underflow of indeterminate sign").

        - tye