Is the most significant decimal digits precision that can be converted to binary and back to decimal without loss of significance 6 or 7.225?

Question

I've come across two different precision formulas for floating-point numbers.

⌊(N-1) log₁₀(2)⌋ = 6 decimal digits (Single-precision)

and

N log₁₀(2) ≈ 7.225 decimal digits (Single-precision)

Where N = 24 Significant bits (Single-precision)

The first formula is found at the top of page 4 of "IEEE Standard 754 for Binary Floating-Point Arithmetic" written by, Professor W. Kahan.

The second formula is found on the Wikipedia article "Single-precision floating-point format" under section IEEE 754 single-precision binary floating-point format: binary32.

For the first formula, Professor W. Kahan says

If a decimal string with at most 6 sig. dec. is converted to Single and then converted back to the same number of sig. dec., then the final string should match the original.

For the second formula, Wikipedia says

...the total precision is 24 bits (equivalent to log₁₀(2²⁴) ≈ 7.225 decimal digits).

The results of both formulas (6 and 7.225 decimal digits) are different, and I expected them to be the same because I assumed they both were meant to represent the most significant decimal digits which can be converted to floating-point binary and then converted back to decimal with the same number of significant decimal digits that it started with.

Why do these two numbers differ, and what is the most significant decimal digits precision that can be converted to binary and back to decimal without loss of significance?

Answer 1

These are talking about two slightly different things.

The 7.225¹ digits is the precision with which a number can be stored internally. For one example, if you did a computation with a double precision number (so you were starting with something like 15 digits of precision), then rounded it to a single precision number, the precision you'd have left at that point would be approximately 7 digits.

The 6 digits is talking about the precision that can be maintained through a round-trip conversion from a string of decimal digits, into a floating point number, then back to another string of decimal digits.

So, let's assume I start with a number like 1.23456789 as a string, then convert that to a float32, then convert the result back to a string. When I've done this, I can expect 6 digits to match exactly. The seventh digit might be rounded though, so I can't necessarily expect it to match (though it probably will be +/- 1 of the original string.

For example, consider the following code:

#include <iostream> #include <iomanip>  int main() {     double init = 987.23456789;     for (int i = 0; i < 100; i++) {         float f = init + i / 100.0;         std::cout << std::setprecision(10) << std::setw(20) << f;     } } 

This produces a table like the following:

     987.2345581         987.2445679         987.2545776         987.2645874      987.2745972         987.2845459         987.2945557         987.3045654      987.3145752          987.324585         987.3345947         987.3445435      987.3545532          987.364563         987.3745728         987.3845825      987.3945923          987.404541         987.4145508         987.4245605      987.4345703         987.4445801         987.4545898         987.4645386      987.4745483         987.4845581         987.4945679         987.5045776      987.5145874         987.5245972         987.5345459         987.5445557      987.5545654         987.5645752          987.574585         987.5845947      987.5945435         987.6045532          987.614563         987.6245728      987.6345825         987.6445923          987.654541         987.6645508      987.6745605         987.6845703         987.6945801         987.7045898      987.7145386         987.7245483         987.7345581         987.7445679      987.7545776         987.7645874         987.7745972         987.7845459      987.7945557         987.8045654         987.8145752          987.824585      987.8345947         987.8445435         987.8545532          987.864563      987.8745728         987.8845825         987.8945923          987.904541      987.9145508         987.9245605         987.9345703         987.9445801      987.9545898         987.9645386         987.9745483         987.9845581      987.9945679         988.0045776         988.0145874         988.0245972      988.0345459         988.0445557         988.0545654         988.0645752       988.074585         988.0845947         988.0945435         988.1045532       988.114563         988.1245728         988.1345825         988.1445923       988.154541         988.1645508         988.1745605         988.1845703      988.1945801         988.2045898         988.2145386         988.2245483 

If we look through this, we can see that the first six significant digits always follow the pattern precisely (i.e., each result is exactly 0.01 greater than its predecessor). As we can see in the original double, the value is actually 98x.xx456--but when we convert the single-precision float to decimal, we can see that the 7^th digit frequently would not be read back in correctly--since the subsequent digit is greater than 5, it should round up to 98x.xx46, but some of the values won't (e.g,. the second to last item in the first column is 988.154541, which would be round down instead of up, so we'd end up with 98x.xx45 instead of 46. So, even though the value (as stored) is precise to 7 digits (plus a little), by the time we round-trip the value through a conversion to decimal and back, we can't depend on that seventh digit matching precisely any more (even though there's enough precision that it will a lot more often than not).

---

^{1. That basically means 7 digits, and the 8th digit will be a little more accurate than nothing, but not a whole lot--for example, if we were converting from a double of 1.2345678, the .225 digits of precision mean that the last digit would be with about +/- .775 of the what started out there (whereas without the .225 digits of precision, it would be basically +/- 1 of what started out there).}

Answer 2

what is the most significant decimal digits precision that can be converted to binary and back to decimal without loss of significance?

The most significant decimal digits precision that can be converted to binary and back to decimal without loss of significance (for single-precision floating-point numbers or 24-bits) is 6 decimal digits.

---

Why do these two numbers differ...

The numbers 6 and 7.225 differ, because they define two different things. 6 is the most decimal digits that can be round-tripped. 7.225 is the approximate number of decimal digits precision for a 24-bit binary integer because a 24-bit binary integer can have 7 or 8 decimal digits depending on its specific value.

7.225 was found using the specific binary integer formula.

d_spec = b·log₁₀(2)             (d_spec = specific decimal digits, b = bits)

However, what you normally need to know, are the minimum and maximum decimal digits for a b-bit integer. The following formulas are used to find the min and max decimal digits (7 and 8 respectively for 24-bits) of a specific binary integer.

d_min = ⌈(b-1)·log₁₀(2)⌉    (d_min = min decimal digits, b = bits, ⌈x⌉ = smallest integer ≥ x)

d_max = ⌈b·log₁₀(2)⌉         (d_max = max decimal digits, b = bits, ⌈x⌉ = smallest integer ≥ x)

To learn more about how these formulas are derived, read Number of Decimal Digits In a Binary Integer, written by Rick Regan.

This is all well and good, but you may ask, why is 6 the most decimal digits for a round-trip conversion if you say that the span of decimal digits for a 24-bit number is 7 to 8?

The answer is — because the above formulas only work for integers and not floating-point numbers!

Every decimal integer has an exact value in binary. However, the same cannot be said for every decimal floating-point number. Take .1 for example. .1 in binary is the number 0.000110011001100..., which is a repeating or recurring binary. This can produce rounding error.

Moreover, it takes one more bit to represent a decimal floating-point number than it does to represent a decimal integer of equal significance. This is because floating-point numbers are more precise the closer they are to 0, and less precise the further they are from 0. Because of this, many floating-point numbers near the minimum and maximum value ranges (e_min = -126 and e_max = +127 for single-precision) lose 1 bit of precision due to rounding error. To see this visually, look at What every computer programmer should know about floating point, part 1, written by Josh Haberman.

Furthermore, there are at least 784,757 positive seven-digit decimal numbers that cannot retain their original value after a round-trip conversion. An example of such a number that cannot survive the round-trip is 8.589973e9. This is the smallest positive number that does not retain its original value.

Here's the formula that you should be using for floating-point number precision that will give you 6 decimal digits for round-trip conversion.

d_max = ⌊(b-1)·log₁₀(2)⌋    (d_max = max decimal digits, b = bits, ⌊x⌋ = largest integer ≤ x)

To learn more about how this formula is derived, read Number of Digits Required For Round-Trip Conversions, also written by Rick Regan. Rick does an excellent job showing the formulas derivation with references to rigorous proofs.

---

As a result, you can utilize the above formulas in a constructive way; if you understand how they work, you can apply them to any programming language that uses floating-point data types. All you have to know is the number of significant bits that your floating-point data type has, and you can find their respective number of decimal digits that you can count on to have no loss of significance after a round-trip conversion.

June 18, 2017 Update: I want to include a link to Rick Regan's new article which goes into more detail and in my opinion better answers this question than any answer provided here. His article is "Decimal Precision of Binary Floating-Point Numbers" and can be found on his website www.exploringbinary.com.