Of the 2**64 possible bit patterns a double can take on only 99.90234375% of them are used to store normal (normalised) floating point values (including +0 & -0).

Of the rest, some 18,014,398,509,481,984 bit patterns: 

#! perl -slw
use strict;
no warnings 'portable';

use constant {
POS_ZERO        => 0b0_00000000000_0000_00000000_00000000_00000000_000
+00000_00000000_00000000,
POS_DENORM_1ST  => 0b0_00000000000_0000_00000000_00000000_00000000_000
+00000_00000000_00000001,
POS_DENORM_LST  => 0b0_00000000000_1111_11111111_11111111_11111111_111
+11111_11111111_11111111,
POS_NORM_1ST    => 0b0_00000000001_0000_00000000_00000000_00000000_000
+00000_00000000_00000000,
POS_NORM_LST    => 0b0_11111111110_1111_11111111_11111111_11111111_111
+11111_11111111_11111111,
POS_INF         => 0b0_11111111111_0000_00000000_00000000_00000000_000
+00000_00000000_00000000,
POS_SNAN_1ST    => 0b0_11111111111_0000_00000000_00000000_00000000_000
+00000_00000000_00000001,
POS_SNAN_LST    => 0b0_11111111111_0111_11111111_11111111_11111111_111
+11111_11111111_11111111,
POS_QNAN_1ST    => 0b0_11111111111_1000_00000000_00000000_00000000_000
+00000_00000000_00000000,
POS_QNAN_LST    => 0b0_11111111111_1111_11111111_11111111_11111111_111
+11111_11111111_11111111,
NEG_ZERO        => 0b1_00000000000_0000_00000000_00000000_00000000_000
+00000_00000000_00000000,
NEG_DENORM_1ST  => 0b1_00000000000_0000_00000000_00000000_00000000_000
+00000_00000000_00000001,
NEG_DENORM_LST  => 0b1_00000000000_1111_11111111_11111111_11111111_111
+11111_11111111_11111111,
NEG_NORM_1ST    => 0b1_00000000001_0000_00000000_00000000_00000000_000
+00000_00000000_00000000,
NEG_NORM_LST    => 0b1_11111111110_1111_11111111_11111111_11111111_111
+11111_11111111_11111111,
NEG_INF         => 0b1_11111111111_0000_00000000_00000000_00000000_000
+00000_00000000_00000000,
NEG_SNAN_1ST    => 0b1_11111111111_0000_00000000_00000000_00000000_000
+00000_00000000_00000001,
NEG_SNAN_LST    => 0b1_11111111111_0111_11111111_11111111_11111111_111
+11111_11111111_11111111,
NEG_IND         => 0b1_11111111111_1000_00000000_00000000_00000000_000
+00000_00000000_00000000,
NEG_QNAN_1ST    => 0b1_11111111111_1000_00000000_00000000_00000000_000
+00000_00000000_00000001,
NEG_QNAN_LST    => 0b1_11111111111_1111_11111111_11111111_11111111_111
+11111_11111111_11111111,
};

printf "%23.16g : %016x\n", unpack( 'd', pack 'Q', $_ ), $_ for
    POS_ZERO, POS_DENORM_1ST, POS_DENORM_LST, POS_NORM_1ST, POS_NORM_L
+ST,
    POS_INF, POS_SNAN_1ST, POS_SNAN_LST,
             POS_QNAN_1ST, POS_QNAN_LST,
    NEG_ZERO, NEG_DENORM_1ST, NEG_DENORM_LST, NEG_NORM_1ST, NEG_NORM_L
+ST,
    NEG_INF, NEG_SNAN_1ST, NEG_SNAN_LST,
    NEG_IND, NEG_QNAN_1ST, NEG_QNAN_LST;

[download]

Produces:

C:\test>ieee.pl
                      0 : 0000000000000000
 4.940656458412465e-324 : 0000000000000001
 2.225073858507201e-308 : 000fffffffffffff
 2.225073858507201e-308 : 0010000000000000
 1.797693134862316e+308 : 7fefffffffffffff
                 1.#INF : 7ff0000000000000
                1.#SNAN : 7ff0000000000001
                1.#SNAN : 7ff7ffffffffffff
                1.#QNAN : 7ff8000000000000
                1.#QNAN : 7fffffffffffffff
                     -0 : 8000000000000000
-4.940656458412465e-324 : 8000000000000001
-2.225073858507201e-308 : 800fffffffffffff
-2.225073858507201e-308 : 8010000000000000
-1.797693134862316e+308 : ffefffffffffffff
                -1.#INF : fff0000000000000
               -1.#SNAN : fff0000000000001
               -1.#SNAN : fff7ffffffffffff
                -1.#IND : fff8000000000000
               -1.#QNAN : fff8000000000001
               -1.#QNAN : ffffffffffffffff

[download]

For completeness, here is the equivelent code in C:

#include <stdio.h>
#include <float.h>

typedef unsigned __int64 U64;

U64 dblPatns[] = {
    0x0000000000000000,    // +zero
    0x0000000000000001, // +denorm lo
    0x000fffffffffffff, // +denorm hi
    0x0010000000000000, // +norm lo
    0x7fefffffffffffff, // +norm hi
    0x7ff0000000000000, // +infinity
    0x7ff0000000000001, // +sNAN lo
    0x7ff7ffffffffffff, // +sNAN hi
    0x7ff8000000000000, // +qNAN lo
    0x7fffffffffffffff, // +qNAN hi
    0x8000000000000000, // -zero
    0x8000000000000001, // -denorm lo
    0x800fffffffffffff, // -denorm hi
    0x8010000000000000, // -norm lo
    0xffefffffffffffff, // -norm hi
    0xfff0000000000000, // -infinity
    0xfff0000000000001, // -sNAN lo
    0xfff7ffffffffffff, // -sNAN hi
    0xfff8000000000000, // -IND ??
    0xfff8000000000001, // -qNAN lo
    0xffffffffffffffff  // -qNAN hi
};

double asDouble( U64 u ) { return *(double*)&u; }

char *FPClassAsText( int class ) {
    switch( class ) {
        case _FPCLASS_SNAN: return "Signaling NaN"; break;
        case _FPCLASS_QNAN: return "Quiet NaN"; break;
        case _FPCLASS_NINF: return "Negative infinity (–INF)"; break;
        case _FPCLASS_NN  : return "Negative normalized non-zero"; bre
+ak;
        case _FPCLASS_ND  : return "Negative denormalized"; break;
        case _FPCLASS_NZ  : return "Negative zero (-0)"; break;
        case _FPCLASS_PZ  : return "Positive zero (+0)"; break;
        case _FPCLASS_PD  : return "Positive denormalized"; break;
        case _FPCLASS_PN  : return "Positive normalized non-zero"; bre
+ak;
        case _FPCLASS_PINF: return "Positive infinity (+INF)"; break;
        default:            return "Never happen; but silence the warn
+ing";
    }
}

int main( int argc, char **argv ) {
    int i;
    for( i = 0; i < sizeof( dblPatns ) / sizeof( U64 ); ++i )
        printf( "%016I64x : % 23.16g %s\n",
            dblPatns[ i ], asDouble( dblPatns[ i ] ),
            FPClassAsText( _fpclass( asDouble( dblPatns[ i ] ) ) )
        );
}

[download]

Which produces:

C:\test>qnan
0000000000000000 :                       0 Positive zero (+0)
0000000000000001 :  4.940656458412465e-324 Positive denormalized
000fffffffffffff :  2.225073858507201e-308 Positive denormalized
0010000000000000 :  2.225073858507201e-308 Positive normalized non-zer
+o
7fefffffffffffff :  1.797693134862316e+308 Positive normalized non-zer
+o
7ff0000000000000 :                  1.#INF Positive infinity (+INF)
7ff0000000000001 :                 1.#SNAN Signaling NaN
7ff7ffffffffffff :                 1.#SNAN Signaling NaN
7ff8000000000000 :                 1.#QNAN Quiet NaN
7fffffffffffffff :                 1.#QNAN Quiet NaN
8000000000000000 :                      -0 Negative zero (-0)
8000000000000001 : -4.940656458412465e-324 Negative denormalized
800fffffffffffff : -2.225073858507201e-308 Negative denormalized
8010000000000000 : -2.225073858507201e-308 Negative normalized non-zer
+o
ffefffffffffffff : -1.797693134862316e+308 Negative normalized non-zer
+o
fff0000000000000 :                 -1.#INF Negative infinity (-INF)
fff0000000000001 :                -1.#SNAN Signaling NaN
fff7ffffffffffff :                -1.#SNAN Signaling NaN
fff8000000000000 :                 -1.#IND Quiet NaN
fff8000000000001 :                -1.#QNAN Quiet NaN
ffffffffffffffff :                -1.#QNAN Quiet NaN

[download]

Note how the oddball -1.#IND is labeled as "Quiet NaN" by the runtime library _fpclass() routine.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.

The start of some sanity?

Replies are listed 'Best First'.
Re: Exploring IEEE754 floating point bit patterns.
by syphilis (Archbishop) on Jul 29, 2012 at 04:35 UTC
    Very interesting stuff.
    They now provide 5 separate symbols for a nan - negative and positive versions of both the signalling and non-signalling nan, plus an extra one (-1.#IND) just in case you are not already sufficiently confused.
    Actually, make that 10 separate symbols, as the 5 nan symbols that appear in the output of BrowserUk's qnan.c, under some circumstances, will be suffixed with '0' ('00' in the case of -1.#IND).

    I wonder why so many symbols are needed ?
    Just one nan symbol would be enough for me - as it is (eg)for the mpfr library.

    It's also interesting that,of my Microsoft compilers (6.0, 7.0 and 8.0), none of them produce the same output as BrowserUk's 9.0 compiler.
    My 8.0 comes closest - the only discrepancy being that it outputs '0' for negative zero instead of '-0'.
    My 6.0 and 7.0 compilers also display negative zero as '0'. Additionally they don't provide the 1.#SNAN symbols - choosing to show them as 1.#QNAN instead, and designating all of the nans as "quiet" nans.

    My gcc (MinGW) compilers (versions 3.4.5, 4.5.2 and 4.7.0) all do the right thing with negative zero but it's only 4.7.0 that goes to the trouble of providing the 1.#SNAN signalling nans.

    It's a pity that the consistency is lacking - but the real puzzle for me is how to predict which of the various 'nans' will be produced by a specific operation.

    An example: 
    #include <stdio.h>
#include <math.h>

int main(void) {
    double x = 1.0;
    double y = 0.0;
    double inf = x /y;
    printf("%f %f\n", inf / inf, -(inf / inf));

    return 0;
}

    [download]
    For that program, my 8.0 MS compiler outputs:
    -1.#IND00 -1.#IND00

    but my gcc-4.5.2 produces:
    -1.#IND00 1.#QNAN0

    Which one is doing it correctly ?

    What operations will result in a signalling nan ?

    Cheers
    Rob
[reply]
[d/l]
      Actually, make that 10 separate symbols, as the 5 nan symbols that appear in the output of BrowserUk's qnan.c, under some circumstances, will be suffixed with '0' ('00' in the case of -1.#IND).I wonder why so many symbols are needed ?

      The suffixing of zeros to the symbols is just an artifact of using "%f" printf format, which implicitly is equivalent to "%.6f" and therefore requires that the fractional part be padded with trailing zeros to 6 places.

      If you adjust the template, you can see this. (The printf from your code above + output):

          printf("%f %f\n",       inf / inf, -(inf / inf)); // -1.#IND00 -1.
+#IND00
    printf("%.4f %.4f\n",   inf / inf, -(inf / inf)); // -1.#IND -1.#I
+ND
    printf("%.10f %.10f\n", inf / inf, -(inf / inf)); // -1.#IND000000
+ -1.#IND000000

      [download]

      I've found %g more useful:

          printf("%g %g\n", inf / inf, -(inf / inf));      // -1.#IND -1.#IN
+D

      [download]
      It's also interesting that,of my Microsoft compilers (6.0, 7.0 and 8.0), none of them produce the same output as BrowserUk's 9.0 compiler.

      The changes are (roughly) in line with the timing of the compiler releases relative to the requirements of the various ANSI C standards C89/C90/C99/C11; and as affected by the updates to the IEEE754 (1987) standard and its revision in 2004. (Roughly:)

      For that program, my 8.0 MS compiler outputs: -1.#IND00 -1.#IND00 but my gcc-4.5.2 produces: -1.#IND00 1.#QNAN0 Which one is doing it correctly ?

      You'll hate this answer. Effectively, they both are!.

      The problem is, the computer scientists and the mathematicians can't agree on a single Function definition with respect to FP math.

      The problem is two-fold:

      1. FP math isn't like real math (Real in the mathematical sense).

        Eg. FP is not always associative: 

        print +( 10.0**20 + 1 ) - 10.0**20;;
0

print +( 10.0**20 - 10.0**20 ) + 1;;
1

        [download]
      2. Mathematicians have conventions for the results of some operations that don't quite work arithmetically.

        Eg. infinity**0 == 1!

        These allow their operations on the continuous Real domain to avoid singularity points

      You pays your money and makes your choice.

      What operations will result in a signalling nan ?

      From what I've been able to discover, none of them! (At least as far as MSC v9 is concerned.)

      The problem here is that the IEEE-754 allows for traps, but doesn't require them. See Signaling NaNs

      My take on what I see coming out of my attempts to produce NaNs with MSC(v9), is that they settled on using -1.#IND as the result of any math operation that is (for want of a better phrase) 'not well defined'. eg. sqrt( -1 ), 0/0; fmod( 1, 0 ) etc.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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.

      The start of some sanity?
[reply]
[d/l]
[select]
        BrowserUk, many thanks for this thread.
        I'm currently trying to make sense of what happens wrt a PDL test script (t/pdl_from_string.t) on MS Windows, and this has helped enormously.

        I now have a clear view of what needs to be done.

        Cheers,
        Rob
[reply]
Re: Exploring IEEE754 floating point bit patterns.
by roboticus (Chancellor) on Jul 28, 2012 at 12:05 UTC

    4.120300081267965e+103:

    Pretty nifty!

    2.914708259813678e+257

    When your only tool is a hammer, all problems look like your thumb.

    P.S. Too bad my perl isn't compiled for 64 bits. I had to use the hack below, as my (un)pack-fu isn't strong. (If I were going to redo any of perls features, it would probably be to make a comprehensible pack/unpack facility.)

    $ cat t.cpp
#include <stdio.h>
#include <string.h>
union f {
    char s[32];
    double d;
} g;

int main(int, char **s) {
    memcpy(g.s, s[1], sizeof(g));
    printf("%23.16g\n", g.d);
}

    [download]

    I think I'll play around with it to make it accept bitstrings.

[reply]
[d/l]
      Too bad my perl isn't compiled for 64 bits.

      Try this version:

      #! perl -slw
use strict;

use constant {
POS_ZERO        => '0'.'00000000000'.'0000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000000',
POS_DENORM_1ST  => '0'.'00000000000'.'0000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000001',
POS_DENORM_LST  => '0'.'00000000000'.'1111'.'11111111'.'11111111'.'111
+11111'.'11111111'.'11111111'.'11111111',
POS_NORM_1ST    => '0'.'00000000001'.'0000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000000',
POS_NORM_LST    => '0'.'11111111110'.'1111'.'11111111'.'11111111'.'111
+11111'.'11111111'.'11111111'.'11111111',
POS_INF         => '0'.'11111111111'.'0000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000000',
POS_SNAN_1ST    => '0'.'11111111111'.'0000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000001',
POS_SNAN_LST    => '0'.'11111111111'.'0111'.'11111111'.'11111111'.'111
+11111'.'11111111'.'11111111'.'11111111',
POS_QNAN_1ST    => '0'.'11111111111'.'1000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000000',
POS_QNAN_LST    => '0'.'11111111111'.'1111'.'11111111'.'11111111'.'111
+11111'.'11111111'.'11111111'.'11111111',
NEG_ZERO        => '1'.'00000000000'.'0000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000000',
NEG_DENORM_1ST  => '1'.'00000000000'.'0000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000001',
NEG_DENORM_LST  => '1'.'00000000000'.'1111'.'11111111'.'11111111'.'111
+11111'.'11111111'.'11111111'.'11111111',
NEG_NORM_1ST    => '1'.'00000000001'.'0000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000000',
NEG_NORM_LST    => '1'.'11111111110'.'1111'.'11111111'.'11111111'.'111
+11111'.'11111111'.'11111111'.'11111111',
NEG_INF         => '1'.'11111111111'.'0000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000000',
NEG_SNAN_1ST    => '1'.'11111111111'.'0000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000001',
NEG_SNAN_LST    => '1'.'11111111111'.'0111'.'11111111'.'11111111'.'111
+11111'.'11111111'.'11111111'.'11111111',
NEG_IND         => '1'.'11111111111'.'1000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000000',
NEG_QNAN_1ST    => '1'.'11111111111'.'1000'.'00000000'.'00000000'.'000
+00000'.'00000000'.'00000000'.'00000001',
NEG_QNAN_LST    => '1'.'11111111111'.'1111'.'11111111'.'11111111'.'111
+11111'.'11111111'.'11111111'.'11111111',
};

sub bitsToDouble{ unpack 'd',  pack 'b64', scalar reverse $_[0] }
sub bitsToInts{   reverse unpack 'VV', pack 'b64', scalar reverse $_[0
+] }

printf "%23.16g : %08x%08x\n",
    bitsToDouble( $_ ), bitsToInts( $_ ) for
    POS_ZERO, POS_DENORM_1ST, POS_DENORM_LST, POS_NORM_1ST, POS_NORM_L
+ST,
    POS_INF, POS_SNAN_1ST, POS_SNAN_LST,
             POS_QNAN_1ST, POS_QNAN_LST,
    NEG_ZERO, NEG_DENORM_1ST, NEG_DENORM_LST, NEG_NORM_1ST, NEG_NORM_L
+ST,
    NEG_INF, NEG_SNAN_1ST, NEG_SNAN_LST,
    NEG_IND, NEG_QNAN_1ST, NEG_QNAN_LST;

      [download]

      Outputs:

      C:\test>\perl32\bin\perl ieee-32b.pl
                      0 : 0000000000000000
 4.940656458412465e-324 : 0000000000000001
 2.225073858507201e-308 : 000fffffffffffff
 2.225073858507201e-308 : 0010000000000000
 1.797693134862316e+308 : 7fefffffffffffff
                 1.#INF : 7ff0000000000000
                1.#QNAN : 7ff0000000000001
                1.#QNAN : 7ff7ffffffffffff
                1.#QNAN : 7ff8000000000000
                1.#QNAN : 7fffffffffffffff
                     -0 : 8000000000000000
-4.940656458412465e-324 : 8000000000000001
-2.225073858507201e-308 : 800fffffffffffff
-2.225073858507201e-308 : 8010000000000000
-1.797693134862316e+308 : ffefffffffffffff
                -1.#INF : fff0000000000000
               -1.#QNAN : fff0000000000001
               -1.#QNAN : fff7ffffffffffff
                -1.#IND : fff8000000000000
               -1.#QNAN : fff8000000000001
               -1.#QNAN : ffffffffffffffff

      [download]

      Seems that the compiler used to build AS 5.8.9 didn't distinguish between SNaN & QNaN. But the oddball -1.#IND was there. Perhaps its presence in the current compiler is legacy code.

      The C version above should compile fine for 32-bit.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      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.

      The start of some sanity?
[reply]
[d/l]
[select]

        BrowserUk:

        That one worked nicely:

        marco@Boink:~
$ perl 984255_bitvec_floats_2.pl
                      0 : 0000000000000000
 4.940656458412465e-324 : 0000000000000001
 2.225073858507201e-308 : 000fffffffffffff
 2.225073858507201e-308 : 0010000000000000
 1.797693134862316e+308 : 7fefffffffffffff
                    inf : 7ff0000000000000
                    nan : 7ff0000000000001
                    nan : 7ff7ffffffffffff
                    nan : 7ff8000000000000
                    nan : 7fffffffffffffff
                     -0 : 8000000000000000
-4.940656458412465e-324 : 8000000000000001
-2.225073858507201e-308 : 800fffffffffffff
-2.225073858507201e-308 : 8010000000000000
-1.797693134862316e+308 : ffefffffffffffff
                   -inf : fff0000000000000
                   -nan : fff0000000000001
                   -nan : fff7ffffffffffff
                   -nan : fff8000000000000
                   -nan : fff8000000000001
                   -nan : ffffffffffffffff

        [download]

        ...roboticus

        When your only tool is a hammer, all problems look like your thumb.

[reply]
[d/l]
Re: Exploring IEEE754 floating point bit patterns.
by pryrt (Abbot) on Jun 23, 2016 at 15:10 UTC

    I know I'm resurrecting an ancient thread, but I was looking at this again while thinking about my Expand.pm module: I think the counts you showed were off: of the 2**64 = 18e18 combinations of the 64bit value, you listed 18e15 non-normalized numbers, of which 9e15 were denormalized, 18e18 were signaling NaN, and 18e18 were quiet NaN, which didn't quite add up right. :-) Here are my tallies:

    Zeroes plus denormals are all the combinations that have the 11 exponent bits of 000_0000_0000, that is: 

        *_000_0000_0000_****_****_****_****_****_****_****_****_****_****_
+****_****_**** 
    => 2^53 = 9,007,199,254,740,992
    => #zeroes = 2
    => #denormals = 9,007,199,254,740,990
        => #positive = 4,503,599,627,370,495
        => #negative = 4,503,599,627,370,495

    [download]

    Infinities plus NaNs take all combinations that have the 11 exponent bits of 111_1111_1111, that is: 

        *_000_0000_0000_****_****_****_****_****_****_****_****_****_****_
+****_****_**** 
    => 2^53 = 9,007,199,254,740,992
    => #infinities = 2
    => #NaNs= 9,007,199,254,740,990
        => #signalling = 4,503,599,627,370,495
        => #quiet      = 4,503,599,627,370,495

    [download]

    That should leave 2**64 - 2*(2**53) for normalized numbers: 

        18,446,744,073,709,551,616 = #64bit values
  -     18,014,398,509,481,984 = #zeroes + #infinities + #denormal + #
+NaN
  = 18,428,729,675,200,069,632 = #normalized numbers

    [download]

    Confirming 2**52, 2**53, 2**54, 2**64, and 2**64 - 2**54 : 

    cmd.exe> perl -MMath::BigInt -E "$b = Math::BigInt->new(2); my $x = ($
+b**$ARGV[0]); $x =~ s/(\d{1,3}?)(?=(\d{3})+$)/$1,/g ; say $x" 52
4,503,599,627,370,496

cmd.exe> perl -MMath::BigInt -E "$b = Math::BigInt->new(2); my $x = ($
+b**$ARGV[0]); $x =~ s/(\d{1,3}?)(?=(\d{3})+$)/$1,/g ; say $x" 53
9,007,199,254,740,992

cmd.exe> perl -MMath::BigInt -E "$b = Math::BigInt->new(2); my $x = ($
+b**$ARGV[0]); $x =~ s/(\d{1,3}?)(?=(\d{3})+$)/$1,/g ; say $x" 54
18,014,398,509,481,984

cmd.exe> perl -MMath::BigInt -E "$b = Math::BigInt->new(2); my $x = ($
+b**$ARGV[0]); $x =~ s/(\d{1,3}?)(?=(\d{3})+$)/$1,/g ; say $x" 64
18,446,744,073,709,551,616

cmd.exe> perl -MMath::BigInt -E "$b = Math::BigInt->new(2); $p1 = Math
+::BigInt->new($ARGV[0]); $p2 = Math::BigInt->new($ARGV[1]); $x = $b**
+$p1; $y = $b**$p2; $z = $x-$y; say join qq|\n|, map { s/(\d{1,3}?)(?=
+(\d{3})+$)/$1,/g; $_ } $x, $y, $z;" 64 54
18,446,744,073,709,551,616
18,014,398,509,481,984
18,428,729,675,200,069,632

    [download]

[reply]
[d/l]
[select]

Back to Cool Uses for Perl