How to convert a uint64_t to a double/float between 0 and 1 with maximum accuracy (C++)?

Question

I'm writing an image class based on unsigned integers. I'm using uint8_t and uint16_t buffers currently for 8-bit and 16-bit RGBA pixels, and to convert from 16-bit to 8-bit I simply have to take the 16 bit value, divide by std::numeric_limits< uint16_t >::max() converted to a double, then multiply that by 255.

However, if I wanted to have an image with 64-bit unsigned integers for each RGBA component (I know, it's absurdly high), how would I go about finding a float/double between 0 and 1 that represents how far between 0 and the max uint64_t my pixel value is? I assume that converting to doubles wouldn't work because doubles are generally 64-bit floats, and you can't capture all 64-bit unsigned integer values in a 64-bit float. Dividing without converting to floats/doubles would just give me 0 or sometimes 1.

What is the most accurate way to find a floating point value between 0 and 1 that represents how far between 0 and the maximum possible an unsigned 64-bit value is?

Answer 1

What is the most accurate way to find a floating point value between 0 and 1 that represents how far between 0 and the maximum possible an unsigned 64-bit value is?

To map integer values in the range [0...2⁶⁴) to [0 ... 1.0) can be done directly.

1. Convert from uint64_t to double.

2. Scale by 2⁶⁴@Mark Ransom

    #define TWO63 0x8000000000000000u 
    #define TWO64f (TWO63*2.0)
   
    double map(uint64_t u) {
      double y = (double) u; 
      return y/Two64f;
    }
   

The will map

Integer values in the range [2⁶³...2⁶⁴) to [0.5 ... 1.0): 2⁵² different double values.
Integer values in the range [2⁶²...2⁶³) to [0.25 ... 0.5): 2⁵² different double values.
Integer values in the range [2⁶¹...2⁶²) to [0.125 ... 0.25): 2⁵² different double values.
...
Integer values in the range [2⁵²...2⁵³) to [2^-12 ... 2^-11): 2⁵² different double values.
Integer values in the range [0...2⁵²) to [2^-13 ... 2^-12): 2⁵² different double values.

---

To map integer values in the range [0...2⁶⁴) to [0 ... 1.0] is more difficult. (Note the ] vs. ).

---

[Feb 2021] I see this answer needs re-explanation on upper edge cases. Potential values returned include 1.0.

Answer 2

You can get a start from the following code for Java's java.util.Random nextDouble() method. It takes 53 bits and forms a double from them:

   return (((long)next(26) << 27) + next(27))
     / (double)(1L << 53);

I would use the most significant 26 bits of your long for the shifted value, and the next 27 bits to fill in the low order bits. That discards the least significant 64-53 = 11 bits of the input.

If distinguishing very small values is especially important you could also use subnormal numbers, which nextDouble() does not return.