They sure look equal…

This is a special bonus extra post in my floating-point series, ranting about an issue that has been a problem for years.

Some debuggers don’t display floats with enough precision.

We count on our programming tools to be precise, and accurate, so when they present us with misleading information for no good reason we should be annoyed. Here is an example:

The debugger is plainly showing me that f1 and f2 have the same value, but it is also showing me that they are not equal. This seems confusing.

Even though comparing floating-point numbers for equality is a a dark endeavor full of traps we should still expect that two floats (and they are both floats, see the ‘Type’ column) that contain the same value should be equal.

Huh.

An expert programmer knows that there are a few things that one can do in order to resolve this ambiguity. One can cast f1 and f2 to double in order to convince the debugger to print them using more digits, or one can display the underlying integer representation. With that done we see that f1 and f2 are indeed different numbers. Their floating-point values are slightly different, and their integer representations differ by one.

It turns out that eight decimal digits of mantissa is not enough to reliably distinguish floats. You need nine.

But why?

That may seem surprising. A float mantissa has 24 bits (if we include the implied one) which gives us 16,777,216 different mantissa values, which is representable in eight digits. However it turns out that if the first digit of the decimal mantissa is small enough, and if the stars align properly, then one extra decimal digit may be required.

Numbers from 1,000 to just below 1,024 are perfect for this. It takes ten binary digits to represent the integer portion (four decimal digits) which leaves fourteen binary digits for the fractional portion. Fourteen binary digits is 16,384 different values. 16,384 different values clearly require five digits to uniquely identify, which means that nine decimal digits (4 + 5) are required to uniquely identify all float numbers in this range, and in fact nine decimal digits (for the mantissa) are sufficient to uniquely identify all float numbers.

On the other hand, numbers from 1,024 to just below 10,000 only require eight decimal digits to uniquely identify. They use eleven or more binary digits for the integer portion, which leaves thirteen or fewer binary digits for the fraction.

9 digits does what?

It’s important to be precise here: nine digits is not enough to fully display the precise value of all float numbers – that actually requires over a hundred digits in some cases (more on that later). However nine digits of mantissa is enough to unambiguously identify which of the ~4 billion floats we are talking about.

Nine digits aren’t needed all the time. Most adjacent floats can be distinguished using just eight digits. Using Float_t and our ability to iterate through all floats it is easy enough to find exactly how many pairs of floats look identical when printed with an eight digit mantissa. Here’s some code:

union Float_t
{
    Float_t(float f1 = 0.0f) : f(f1) {}

    int32_t i;
    float f;
    struct
    {
        uint32_t mantissa : 23;
        uint32_t exponent : 8;
        uint32_t sign : 1;
    } parts;
};

void Count9PrintFloats()
{
    int matchCount = 0;
    uint32_t lastExponent = 0;
    Float_t allFloats(0.0f);

    char buffer[30];
    sprintf_s(buffer, “%1.7e”, allFloats.f);
    while (allFloats.parts.exponent < 255)
    {
        allFloats.i += 1;
        char buf2[_countof(buffer)];
        sprintf_s(buf2, “%1.7e”, allFloats.f);
        if (strcmp(buffer, buf2) == 0)
            matchCount += 1;
        strcpy_s(buffer, buf2);

        if (allFloats.parts.exponent != lastExponent)
        {
            printf(“%d matches found up to exponent %u.\n”,
                    matchCount, lastExponent);
            lastExponent = allFloats.parts.exponent;
        }
    }

    printf(“%d matches found.\n”, matchCount);
}

This program took a bit less than half an hour to iterate through all 2 billion positive floats and it found 32,226,412 pairs of floats that require nine digit decimal mantissas to distinguish. In other words, roughly 6% of all floats need to be printed with a nine-digit mantissa.

Visual Studio (versions 2005, 2010, and VS 11 Developer preview all behave identically) display floats with eight digits of precision, and this is insufficient. They need to display them with nine. They are sooo close. I am hopeful that this can be corrected before VS 11 ships. Finally.

In your own development if you want your floating point numbers to round-trip from float to decimal and back I recommend printing them like this:

printf_s("%1.8e", 8);

If printed in this manner you should get nine digits of mantissa and when you sscanf them back into memory you should get back the exact float that you started with.

Other debuggers

WinDbg gets this right. It displays floats with 10 digits of precision.

Doubles

Both VS and WinDb display doubles with 17 digits of precision. There are two reasons for this:

1. 17 decimal digits of mantissa is how many is required to uniquely identify a double.
2. 17 decimal digits of mantissa is the most that VC++ will print.

If you ask VC++ to print more than 17 digits (printf(“%1.30e”, d1);) then the extra digits will all be zeroes, even though that is usually not the correct value. This is standards compliant, but annoying. We’ll deal with this problem, and explore how many digits it takes to perfectly represent the value of a float, in a subsequent post.