ig has asked for the wisdom of the Perl Monks concerning the following question:

I would like to better understand Perl's ability and limitations processing floating point numbers. Does anyone have suggestions for my reading list?

I believe 1.79769313486232e+308 is the largest IEEE-754 double precision floating point number. Perl (32 bit on CentOS on Intel based system) can store this value in a scalar and print it but does not accept it as a numeric literal.

use strict; use warnings; use Devel::Peek; my $foo = pack("H16", "FFFFFFFFFFFFEF7F" ); Dump($foo); my $bar = unpack("d", $foo); Dump($bar); my $x = $bar; Dump($x); my $y = 1.79769313486232e+308; Dump($y); __END__ SV = PV(0x99490a0) at 0x995b760 REFCNT = 1 FLAGS = (PADMY,POK,pPOK) PV = 0x9956ba8 "\377\377\377\377\377\377\357\177"\0 CUR = 8 LEN = 12 SV = NV(0x99832d8) at 0x995b7b0 REFCNT = 1 FLAGS = (PADMY,NOK,pNOK) NV = 1.79769313486232e+308 SV = NV(0x99832d0) at 0x995b740 REFCNT = 1 FLAGS = (PADMY,NOK,pNOK) NV = 1.79769313486232e+308 SV = NV(0x99832e0) at 0x9968360 REFCNT = 1 FLAGS = (PADMY,NOK,pNOK) NV = inf

As you can see from the above example, pack and unpack can be used to get this maximal value into a scalar and this value can be assigned from one scalar to another but using this value as a literal results in 'inf' instead of the expected value.

Any comments on why this is so?

update: The value of the largest IEEE-754 double precision floating point number, expressed as a base 10 integer is:

1797693134862315708145274237317043567980705675258449965989174768031572 +607800285387605895586327668781715404589535143824642343213268894641827 +684675467035375169860499105765512820762454900903893289440758685084551 +339423045832369032229481658085593321233482747978262041447231687381771 +80919299881250404026184124858368

The precision of an IEEE-754 double precision floating point value is approximately 16 decimal digits. Therefore, many numeric literals will be converted to this maximal value, including 1.7976931348623157e+308

When this maximal value is interpolated into a string, it is rounded to 15 digits of precision and the value it is rounded up to, when used as a numeric literal, is converted to inf rather than back to the maximum value. This value is: 1.79769313486232e+308.

Replies are listed 'Best First'.
Re: Large floating point literals
by BrowserUk (Patriarch) on May 20, 2009 at 21:20 UTC

      Thanks!! I had, foolishly, not considered that the displayed base 10 might be rounded.

      Several literals slightly larger than 1.797693134862314e+308 are converted to non-infinite numbers, including two in the following test that are converted to what I believe is the largest possible value.

        Indeed. You are correct. I chose the wrong reference:

        printf "%.20g\n", unpack 'd', scalar reverse pack 'NN', 0x7fefffff, 0x +ffffffff;; 1.7976931348623157e+308 printf "%.20g\n", unpack 'd', scalar reverse pack 'NN', 0x7fffffff, 0x +ffffffff;; 1.#QNAN printf "%.20g\n", unpack 'd', scalar reverse pack 'NN', 0xffefffff, 0x +ffffffff;; -1.7976931348623157e+308 printf "%.20g\n", unpack 'd', scalar reverse pack 'NN', 0xffffffff, 0x +ffffffff;; -1.#QNAN

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Large floating point literals
by zwon (Abbot) on May 20, 2009 at 21:22 UTC

    The same on 64 bit Ubuntu, but the following gives me desired number:

    $ perl -E'my $a=-1.797693134862314e+308; say $a;' -1.79769313486232e+308

    I think while converting number into binary representation perl (actually underlying c library) may loose precision, that's why you getting inf