In IEEE Floats and Python, I chose to use a tiny "binary6" type because it's easy to show a table of values that helps clarify things.

Someone suggested that you could just as easily write a table of binary64 values, ellipsizing large chunks of it, and it would also be useful for clarifying things. And I think he's right.

The Table

    sign  exponent significand    binary scientific              decimal
       0 000...000 0000...0000    0.0...0000e-1022 = 0           0.0
       0 000...000 0000...0001    0.0...0001e-1022 = 1.0e-1074   5e-324
       0 000...000 0000...0010    0.0...0010e-1022 = 1.0e-1073   1e-323
       0 000...000 0000...0011    0.0...0011e-1022 = 1.1e-1073   1.5e-323
       0 000...000 0000...0100    0.0...0100e-1022 = 1.0e-1072   2e-323
       0 000...000 0000...0101    0.0...0101e-1022 = 1.01e-1072  2.5e-323
       0 000...000 0000...0110    0.0...0110e-1022 = 1.10e-1072  3e-323
       0 000...000 0000...0111    0.0...0111e-1022 = 1.11e-1072  3.5e-323
       0 000...000 0000...1100    0.0...1100e-1022 = 1.0e-1071   4e-323
       0 000...000 0000...1101    0.0...1101e-1022 = 1.01e-1071  4.4e-323
       0 000...000 0000...1110    0.0...1110e-1022 = 1.10e-1072  5e-323
       0 000...000 0000...1111    0.0...1111e-1022 = 1.11e-1072  5.4e-323
       ...
       0 000...000 1111...1110    0.1...1110e-1022 = 1.11e-1023  2.2250738585072004e-308
       0 000...000 1111...1111    0.1...1111e-1022 = 1.11e-1023  2.225073858507201e-308
       0 000...001 0000...0000    1.0...0000e-1022 = 1.0e-1022   2.2250738585072014e-308
       0 000...001 0000...0001    1.0...0001e-1022               2.225073858507202e-308
       ...
       0 000...001 1111...1111    1.1...1111e-1022               4.4501477170144023e-308
       0 000...010 0000...0000    1.0...0000e-1021               4.450147717014403e-308
       ...
       0 011...110 1111...1111    1.1...111e-1                   0.9999999999999999
       0 011...111 0000...0000    1.0...000e0                    1.0
       0 011...111 0000...0001    1.0...001e0                    1.0000000000000002
       ...
       0 111...101 1111...1111    1.1...111e+1022                8.988465674311579e+307
       0 111...110 0000...0000    1.0...000e+1023                8.98846567431158e+307
       0 111...110 0000...0001    1.0...001e+1023                8.988465674311582e+307
       ...
       0 111...110 1111...1110    1.1...110e+1023                1.7976931348623155e+308
       0 111...110 1111...1111    1.1...111e+1023                1.7976931348623157e+308
       0 111...111 0000...0000    inf                            inf
       0 111...111 0000...0001    snan1                          snan1
       0 111...111 0000...0010    snan10                         snan2
       ...
       0 111...111 0111...1111    snan1...1                      snan2251799813685247
       0 111...111 1000...0000    qnan0                          qnan0
       0 111...111 1000...0001    qnan1                          qnan1
       0 111...111 1000...0010    qnan10                         qnan2
       0 111...111 1111...1111    qnan1...1                      qnan2251799813685247
       1 000...000 0000...0000    -0.0...0000e-1022 = -0         -0.0
       0 000...000 0000...0001    -0.0...0001e-1022 = -1.0e-1074 -5e-324
       ...
       1 111...111 0000...0000    -inf                           -inf
       1 111...111 0000...0001    -snan1                         -snan1
       ...
       1 111...111 1000...0000    -qnan0                         -qnan0
       1 111...111 1111...1111    -qnan1...1                     -qnan2251799813685247

Notes

For finite numbers, I've displayed the decimal representation the same way Python 3.5 does (the shorted decimal fraction that rounds to the same binary fraction). For NaN values, Python displays them all as just "nan". Some C libraries will display something like "QNaN(1)" or "qnan1" or the like, so I've chosen to do that for clarity.

As mentioned in the previous post, this is for IEEE 754-2008 binary64, even though your platform (assuming you're not reading this in some far-future era where C11 and Python 3.5 are distant memories but blogspot posts are still relevant) probably uses the older IEEE 754-1985 double type, which is a slightly looser version of the same thing. So if you're on some older platform, a few things may be different (e.g., Irix on MIPS has snan and qnan reversed).

Generating the table yourself

Using the floatextras module, you can generate the values yourself. If it's not quite as easy as maybe it could be, suggestions are welcome.

One trick that helps a bit is that the make_tuple function can take any sequence of digits, or an int, which will be interpreted as an unsigned 52-bit integer:

    >>> from_tuple((0, -1, 0))
    1.9999999999999998

Unfortunately, you still have to turn that into bits to print the significand column of the table. I guess you could recover them from the float with as_tuple, but that seems silly. (I used the bitstring library again.) Maybe a function for generating table rows given either a float or a tuple and a +/- range would be useful?