可以在不损失重要性的情况下转换为二进制并返回十进制的最高有效十进制数字精度是 6 还是 7.225？

我遇到过两种不同的浮点数精度公式。

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

and

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

Where N = 24有效位（单精度）

第一个公式位于“的第 4 页顶部”二进制浮点运算的 IEEE 标准 754 http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF” 写的,W·卡汉教授.

第二个公式可以在维基百科文章“单精度浮点格式 http://en.wikipedia.org/wiki/Single-precision_floating-point_format” 部分下IEEE 754 单精度二进制浮点格式：binary32.

对于第一个公式，W. Kahan 教授说

如果十进制字符串至多 6 sig。十二月转换为 Single，然后转换回相同数量的 sig。十二月， 那么最终的字符串应该与原始字符串匹配。

对于第二个公式，维基百科说

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

两个公式的结果（6 和 7.225 十进制数字）是不同的，我希望它们是相同的，因为我假设它们都表示最高有效的十进制数字，可以转换为浮点二进制，然后再转换回来转换为十进制，其有效小数位数与开始时的位数相同。

为什么这两个数字不同，可以转换为二进制并返回十进制而不丢失重要性的最高有效十进制数字精度是多少？

这些谈论的是两个略有不同的事情。

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.

6位数字说的是可以保持的精度through从一串十进制数字到浮点数，然后返回到另一个十进制数字字符串的往返转换。

所以，假设我从一个像这样的数字开始1.23456789作为字符串，然后将其转换为 float32，然后将结果转换回字符串。当我完成此操作后，我可以期望 6 位数字完全匹配。不过，第七位数字可能会被四舍五入，所以我不一定期望它匹配（尽管它可能是原始字符串的+/-1。

例如，考虑以下代码：

#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;
    }
}

这会生成如下表：

     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).}