Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re: Numeric overloading with 64-bit Perl

by tonyc (Pilgrim)
on Oct 06, 2005 at 12:11 UTC ( #497894=note: print w/replies, xml ) Need Help??

in reply to Numeric overloading with 64-bit Perl

I suspect the problem you're running into is the way perl converts numbers to strings, not the way it's storing them.

By default perl will format numbers as if sprintf()ed with a format of "%.Ng" where N is the value of DBL_DIG for your platform. To check this value run:

perl -MPOSIX -le "print DBL_DIG"

On my system this is 15, if it's the same on your platform, this could explain why you're seeing the change when moving from 15 to 16 digits.

To see how perl is actually storing the number use Devel:Peek:

perl -MDevel::Peek -le '$x = 1000000000000000; Dump($x)'

For a use64bitint perl this produced:

SV = IV(0x80cba4) at 0x800d1c REFCNT = 1 FLAGS = (IOK,pIOK) IV = 1000000000000000

If you want numbers formatted to higher precision on output, you'll need to either change $#, or use printf with an appropriate format.

Replies are listed 'Best First'.
Re^2: Numeric overloading with 64-bit Perl
by jdhedden (Deacon) on Oct 06, 2005 at 13:42 UTC
    No, it is not the result of number-to-string conversion. Consider the following:
    my $x = 100000000000000; for my $ii (14..25) { print("10^$ii: ", 0 + $x, "\n"); $x *= 10; }
    which outputs:
    10^14: 100000000000000
    10^15: 1000000000000000
    10^16: 10000000000000000
    10^17: 100000000000000000
    10^18: 1000000000000000000
    10^19: 10000000000000000000
    10^20: 1e+20
    10^21: 1e+21
    10^22: 1e+22
    10^23: 1e+23
    10^24: 1e+24
    10^25: 1e+25
    This shows that Perl can output 20-digit integers, and verifies that the integer return value is being coerced into a floating-point result by the overload handling code.

    Remember: There's always one more bug.

      You're right. Sorry for the assumption.

      I think I see the cause of the problem. If you look at pp_add (pp_hot.c) you'll see that it checks for the IV and UV flags on the scalar (SvIOK, SvUOK) and since neither of these is set it falls through to do the arithmetic with NVs.

      To fix this the magic code would need to be hoisted out of sv_2iv_flags() and the check for SvIOK (or SvUOK) done on the scalar returned by the numeric overload.

      Fixing this for every operator would be a big change.

      Edit: pp_add is in pp_hot.c, not sv.c

        I put in a bug report for this. Thanks for the confirmation.

        Remember: There's always one more bug.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://497894]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (10)
As of 2017-03-25 15:51 GMT
Find Nodes?
    Voting Booth?
    Should Pluto Get Its Planethood Back?

    Results (311 votes). Check out past polls.