为什么C和Java的round floats不一样？

Question

考虑浮点数0.644696875。让我们用Java和C把它转换成八位小数的字符串:

import java.lang.Math;
public class RoundExample{
     public static void main(String[] args){
        System.out.println(String.format("%10.8f",0.644696875));
     }
}

结果：0.64469688

自己试试吧：http://tpcg.io/oszC0w

#include <stdio.h>

int main()
{
    printf("%10.8f", 0.644696875); //double to string
    return 0;
}

结果：0.64469687

自己试试吧：http://tpcg.io/fQqSRF

为什么最后一个数字不同？

数字0.644696875不能精确地表示为机器号。它表示为分数2903456606016923/4503599627370496，其值为0.64668799999

诚然，这是一个边缘案例。但我真的很好奇差异的来源。

相关： https://mathematica.stackexchange.com/questions/204359/is-numberform-double-rounding-numbers

Answer 1

这里可能发生的情况是，他们使用稍微不同的方法将数字转换为字符串，这引入了舍入误差。在编译过程中，字符串转换为浮点的方法也可能不同，由于舍入，它们的值也可能略有不同。

但是请记住，float的小数精度为24位，也就是大约7.22个十进制数字[log10(2)*24]，前7个数字是一致的，因此只有最后几个最低有效位不同。

欢迎来到浮点数学的有趣世界，2 2并不总是等于4。

Answer 2

在这种情况下，Java 规范需要麻烦的双舍五入。数字 0.6446968749999999470645661858725361526012420654296875 首先转换为 0.644696875，然后舍入为 0.64469688。

相比之下，C实现简单地将0.64469687499947064566185872536156012420654296875直接四舍五入到8位，产生0.6446 9687。

对于双精度型，Java 使用 IEEE-754 基本 64 位二进制浮点数。在此格式中，最接近源文本中数字的值 0.644696875 是 0.64469696874999999470645661858725361526012420654296875，我相信这是使用 String.format（“.8f”，0.644696875） 格式化的实际值。¹

使用< code>Double类型和< code>f格式进行格式化的文档说明如下:

…如果精度小于分别由< code > float . tostring(float)或< code > double . tostring(double)返回的字符串中小数点后出现的位数，则将使用round half up算法对值进行舍入。否则，可能会附加零以达到精度…

让我们考虑“由…< code > double . tostring(double)返回的字符串”。对于数字0.6446968749999999470645661858725361526012420654296875，此字符串为“0.644696875”。这是因为Java规范规定< code>toString产生的十进制数字刚好足以唯一区分< code>Double值集合中的数字，在这种情况下,“0.644696875”刚好有足够的数字。第2页

该数字在小数点后有九位数字，“.8f”请求八位，因此上面引用的段落说“值”是四舍五入的。它指的是哪个值 - 格式的实际操作数，即 0.64469696874999999470645661858725361526012420654296875，还是它提到的字符串“0.644696875”？由于后者不是数值，我本来以为“值”是指前者。但是，第二句话说“否则[即，如果请求更多数字]，可能会附加零......”如果我们使用格式的实际操作数，我们将显示其数字，而不是使用零。但是，如果我们将字符串作为数值，则其十进制表示形式在中显示的数字后面将只有零。因此，这似乎是预期的解释，而Java实现似乎符合这一点。

因此，要使用".8f"格式化这个数字，我们首先将其转换为0.644696875，然后使用舍入半向上规则对其进行舍入，从而产生0.64469688。

这是一个糟糕的规范，因为：

• 它需要两次舍入，这可能会增加误差。
• 舍入发生在难以预测和难以控制的地方。某些值将在小数点后两位后四舍五入。有些将在13之后四舍五入。程序无法轻松预测或调整它。

（另外，很遗憾他们写了零“可能”附加。为什么不“否则，附加零以达到精度”？对于“may”，似乎他们给了实现一个选择，尽管我怀疑他们的意思是“可能”是基于是否需要零来达到精度，而不是基于实现者是否选择附加它们。

¹当源代码中的0.644696875转换为Double时，我相信结果应该是Double格式中可表示的最接近值。（我没有在Java留档中找到它，但它符合要求实现行为相同的Java哲学，我怀疑转换是根据Double.valueOf（String s）完成的，它确实需要这个。）最接近0.644696875的Double是0.64469687499999470645661858725361526012420654296875。

²如果数字较少，七位数0.64469687是不够的，因为最接近它的Double值为0.6446968699999999774519210404832847416400909423828125。所以需要八位数字来唯一区分0.64469687499999470645661858725361526012420654296875。