考虑以下代码:
0.1 + 0.2 == 0.3 -> false
0.1 + 0.2 -> 0.30000000000000004
为什么会出现这些错误?
考虑以下代码:
0.1 + 0.2 == 0.3 -> false
0.1 + 0.2 -> 0.30000000000000004
为什么会出现这些错误?
当前回答
十进制数(如0.1、0.2和0.3)在二进制编码浮点类型中没有精确表示。0.1和0.2的近似值之和与0.3的近似值不同,因此,0.1+0.2==0.3的错误在这里可以更清楚地看到:
#include <stdio.h>
int main() {
printf("0.1 + 0.2 == 0.3 is %s\n", 0.1 + 0.2 == 0.3 ? "true" : "false");
printf("0.1 is %.23f\n", 0.1);
printf("0.2 is %.23f\n", 0.2);
printf("0.1 + 0.2 is %.23f\n", 0.1 + 0.2);
printf("0.3 is %.23f\n", 0.3);
printf("0.3 - (0.1 + 0.2) is %g\n", 0.3 - (0.1 + 0.2));
return 0;
}
输出:
0.1 + 0.2 == 0.3 is false
0.1 is 0.10000000000000000555112
0.2 is 0.20000000000000001110223
0.1 + 0.2 is 0.30000000000000004440892
0.3 is 0.29999999999999998889777
0.3 - (0.1 + 0.2) is -5.55112e-17
为了更可靠地计算这些计算,您需要对浮点值使用基于十进制的表示。C标准没有默认指定此类类型,而是作为技术报告中描述的扩展。
_Decimal32、_Decimal64和_Decimal128类型可能在您的系统上可用(例如,GCC在选定的目标上支持它们,但Clang在OS X上不支持它们)。
其他回答
从Python 3.5开始,您可以使用math.isclose()函数来测试近似相等性:
>>> import math
>>> math.isclose(0.1 + 0.2, 0.3)
True
>>> 0.1 + 0.2 == 0.3
False
已经发布了很多好的答案,但我想再补充一个。
并非所有数字都可以通过浮点数/双精度表示例如,在IEEE754浮点标准中,数字“0.2”将以单精度表示为“0.200000003”。
用于在引擎盖下存储实数的模型将浮点数表示为
即使您可以轻松键入0.2,FLT_RADIX和DBL_RADIX都是2;对于使用“IEEE二进制浮点运算标准(ISO/IEC Std 754-1985)”的带有FPU的计算机,不是10。
所以准确地表示这些数字有点困难。即使在没有任何中间计算的情况下显式指定此变量。
我的答案很长,所以我把它分成了三部分。因为这个问题是关于浮点数学的,所以我把重点放在了机器的实际功能上。我还将其指定为双精度(64位),但该参数同样适用于任何浮点运算。
序言
IEEE 754双精度二进制浮点格式(binary64)数字表示以下形式的数字
值=(-1)^s*(1.m51m50…m2m1m0)2*2e-1023
64位:
第一位是符号位:如果数字为负,则为1,否则为0。接下来的11位是指数,偏移1023。换句话说,在从双精度数字中读取指数位之后,必须减去1023以获得2的幂。剩下的52位是有效位(或尾数)。在尾数中,“隐含”1。由于任何二进制值的最高有效位为1,因此总是省略2。
1-IEEE 754允许有符号零的概念-+0和-0被不同地对待:1/(+0)是正无穷大;1/(-0)是负无穷大。对于零值,尾数和指数位均为零。注意:零值(+0和-0)未明确归为非标准2。
2-非正规数的情况并非如此,其偏移指数为零(以及隐含的0)。非正规双精度数的范围为dmin≤|x|≤dmax,其中dmin(最小的可表示非零数)为2-1023-51(≈4.94*10-324),dmax(最大的非正规数,其尾数完全由1组成)为2-1023+1-21-23-51(≈2.225*10-308)。
将双精度数字转换为二进制
存在许多在线转换器来将双精度浮点数转换为二进制(例如,在binaryconvert.com),但这里有一些示例C#代码来获得双精度数字的IEEE 754表示(我用冒号(:)分隔这三个部分:
public static string BinaryRepresentation(double value)
{
long valueInLongType = BitConverter.DoubleToInt64Bits(value);
string bits = Convert.ToString(valueInLongType, 2);
string leadingZeros = new string('0', 64 - bits.Length);
string binaryRepresentation = leadingZeros + bits;
string sign = binaryRepresentation[0].ToString();
string exponent = binaryRepresentation.Substring(1, 11);
string mantissa = binaryRepresentation.Substring(12);
return string.Format("{0}:{1}:{2}", sign, exponent, mantissa);
}
开门见山:最初的问题
(对于TL;DR版本,跳到底部)
卡托·约翰斯顿(提问者)问为什么0.1+0.2!=0.3.
以二进制(用冒号分隔三个部分)编写,IEEE 754值表示为:
0.1 => 0:01111111011:1001100110011001100110011001100110011001100110011010
0.2 => 0:01111111100:1001100110011001100110011001100110011001100110011010
请注意,尾数由0011的重复数字组成。这是为什么计算有任何错误的关键-0.1、0.2和0.3不能用二进制精确地表示在有限数量的二进制位中,任何超过1/9、1/3或1/7的二进制位都可以用十进制数字精确地表示。
还要注意,我们可以将指数的幂减小52,并将二进制表示中的点向右移动52位(非常类似10-3*1.23==10-5*123)。这使我们能够将二进制表示表示为它以a*2p形式表示的精确值。其中“a”是整数。
将指数转换为十进制、删除偏移量并重新添加隐含的1(在方括号中)、0.1和0.2为:
0.1 => 2^-4 * [1].1001100110011001100110011001100110011001100110011010
0.2 => 2^-3 * [1].1001100110011001100110011001100110011001100110011010
or
0.1 => 2^-56 * 7205759403792794 = 0.1000000000000000055511151231257827021181583404541015625
0.2 => 2^-55 * 7205759403792794 = 0.200000000000000011102230246251565404236316680908203125
要添加两个数字,指数必须相同,即:
0.1 => 2^-3 * 0.1100110011001100110011001100110011001100110011001101(0)
0.2 => 2^-3 * 1.1001100110011001100110011001100110011001100110011010
sum = 2^-3 * 10.0110011001100110011001100110011001100110011001100111
or
0.1 => 2^-55 * 3602879701896397 = 0.1000000000000000055511151231257827021181583404541015625
0.2 => 2^-55 * 7205759403792794 = 0.200000000000000011102230246251565404236316680908203125
sum = 2^-55 * 10808639105689191 = 0.3000000000000000166533453693773481063544750213623046875
由于和的形式不是2n*1.{bbb},我们将指数增加1,并移动小数(二进制)点以获得:
sum = 2^-2 * 1.0011001100110011001100110011001100110011001100110011(1)
= 2^-54 * 5404319552844595.5 = 0.3000000000000000166533453693773481063544750213623046875
现在尾数中有53位(第53位在上一行的方括号中)。IEEE 754的默认舍入模式是“舍入到最近”,即如果数字x介于两个值a和b之间,则选择最低有效位为零的值。
a = 2^-54 * 5404319552844595 = 0.299999999999999988897769753748434595763683319091796875
= 2^-2 * 1.0011001100110011001100110011001100110011001100110011
x = 2^-2 * 1.0011001100110011001100110011001100110011001100110011(1)
b = 2^-2 * 1.0011001100110011001100110011001100110011001100110100
= 2^-54 * 5404319552844596 = 0.3000000000000000444089209850062616169452667236328125
注意,a和b仅在最后一位不同。。。0011 + 1 = ...0100。在这种情况下,最低有效位为零的值为b,因此总和为:
sum = 2^-2 * 1.0011001100110011001100110011001100110011001100110100
= 2^-54 * 5404319552844596 = 0.3000000000000000444089209850062616169452667236328125
而0.3的二进制表示是:
0.3 => 2^-2 * 1.0011001100110011001100110011001100110011001100110011
= 2^-54 * 5404319552844595 = 0.299999999999999988897769753748434595763683319091796875
其仅与0.1和0.2之和的二进制表示相差2-54。
0.1和0.2的二进制表示是IEEE 754允许的数字的最精确表示。由于默认舍入模式,添加这些表示会导致一个仅在最低有效位不同的值。
TL;博士
将0.1+0.2写入IEEE 754二进制表示(用冒号分隔三个部分),并将其与0.3进行比较,这是(我将不同的位放在方括号中):
0.1 + 0.2 => 0:01111111101:0011001100110011001100110011001100110011001100110[100]
0.3 => 0:01111111101:0011001100110011001100110011001100110011001100110[011]
转换回十进制,这些值为:
0.1 + 0.2 => 0.300000000000000044408920985006...
0.3 => 0.299999999999999988897769753748...
与原始值相比,差异正好为2-54,约为5.5511151231258×10-17(对于许多应用)。
比较浮点数的最后几位本来就很危险,任何读过著名的《每一位计算机科学家都应该知道的关于浮点运算》(该书涵盖了这个答案的所有主要部分)的人都会知道。
大多数计算器使用额外的保护数字来解决这个问题,这就是0.1+0.2如何给出0.3:最后几位是四舍五入的。
在硬件级别,浮点数表示为二进制数的分数(以2为基数)。例如,小数:
0.125
具有1/10+2/100+5/1000的值,并且以相同的方式,具有二进制分数:
0.001
值为0/2+0/4+1/8。这两个分数具有相同的值,唯一的区别是第一个是小数,第二个是二进制分数。
不幸的是,大多数十进制分数不能用二进制分数表示。因此,通常情况下,您给出的浮点数仅近似于存储在机器中的二进制分数。
这个问题在基础10中更容易解决。以分数1/3为例。您可以将其近似为小数:
0.3
或更好,
0.33
或更好,
0.333
无论你写了多少个小数点,结果永远不会精确到1/3,但这是一个总是更接近的估计。
同样,无论使用多少个以2为基数的小数位数,小数值0.1都不能精确地表示为二进制小数。在基数2中,1/10是以下周期数:
0.0001100110011001100110011001100110011001100110011 ...
停止在任何有限数量的比特,你会得到一个近似值。
对于Python,在典型的机器上,53位用于浮点的精度,因此输入小数0.1时存储的值是二进制小数。
0.00011001100110011001100110011001100110011001100110011010
其接近但不完全等于1/10。
很容易忘记存储的值是原始小数的近似值,因为在解释器中显示浮点的方式。Python只显示二进制存储值的十进制近似值。如果Python要输出存储为0.1的二进制近似值的真正十进制值,它将输出:
>>> 0.1
0.1000000000000000055511151231257827021181583404541015625
这比大多数人预期的小数位数要多得多,因此Python显示舍入值以提高可读性:
>>> 0.1
0.1
重要的是要理解,在现实中这是一种错觉:存储的值不完全是1/10,只是在显示器上存储的值被舍入。当您使用这些值执行算术运算时,这一点就会变得明显:
>>> 0.1 + 0.2
0.30000000000000004
这种行为是机器浮点表示的本质所固有的:它不是Python中的错误,也不是代码中的错误。你可以在所有其他语言中观察到相同类型的行为使用硬件支持计算浮点数(尽管有些语言默认情况下不使差异可见或在所有显示模式下不可见)。
另一个令人惊讶的地方就在这一点上。例如,如果尝试将值2.675舍入到两位小数,则会得到
>>> round (2.675, 2)
2.67
round()原语的文档表明它舍入到离零最近的值。由于小数正好在2.67和2.68之间的一半,因此应该可以得到2.68(二进制近似值)。然而,情况并非如此,因为当小数2.675转换为浮点时,它由精确值为:
2.67499999999999982236431605997495353221893310546875
由于近似值比2.68略接近2.67,因此舍入值降低。
如果您处于小数向下舍入的情况,那么应该使用十进制模块。顺便说一下,十进制模块还提供了一种方便的方式来“查看”为任何浮点存储的确切值。
>>> from decimal import Decimal
>>> Decimal (2.675)
>>> Decimal ('2.67499999999999982236431605997495353221893310546875')
0.1不是精确存储在1/10中这一事实的另一个结果是十个值的总和0.1也不等于1.0:
>>> sum = 0.0
>>> for i in range (10):
... sum + = 0.1
...>>> sum
0.9999999999999999
二进制浮点数的算术有很多这样的惊喜。“0.1”的问题将在下文“表示错误”一节中详细解释。有关此类惊喜的更完整列表,请参阅浮点运算的危险。
确实没有简单的答案,但是不要对浮动虚拟数字过分怀疑!在Python中,浮点数操作中的错误是由底层硬件造成的,在大多数机器上,每次操作的错误率不超过1/2*53。这对于大多数任务来说都是非常必要的,但您应该记住,这些操作不是十进制操作,并且对浮点数字的每一次操作都可能会出现新的错误。
尽管存在病态的情况,但对于大多数常见的用例,您只需在显示器上舍入到所需的小数位数,就可以在最后得到预期的结果。有关如何显示浮点数的详细控制,请参阅字符串格式语法以了解str.format()方法的格式规范。
答案的这一部分详细解释了“0.1”的示例,并展示了如何自己对此类案例进行精确分析。我们假设您熟悉浮点数的二进制表示。术语表示错误意味着大多数小数不能用二进制精确表示。这就是为什么Python(或Perl、C、C++、Java、Fortran等)通常不会以十进制显示精确结果的主要原因:
>>> 0.1 + 0.2
0.30000000000000004
为什么?1/10和2/10不能用二进制分数精确表示。然而,今天(2010年7月)所有的机器都遵循IEEE-754标准来计算浮点数。大多数平台使用“IEEE-754双精度”来表示Python浮点。双精度IEEE-754使用53位精度,因此在读取时,计算机尝试将0.1转换为J/2*N形式的最接近分数,J正好是53位的整数。重写:
1/10 ~ = J / (2 ** N)
in :
J ~ = 2 ** N / 10
记住J正好是53位(所以>=2**52但<2**53),N的最佳可能值是56:
>>> 2 ** 52
4503599627370496
>>> 2 ** 53
9007199254740992
>>> 2 ** 56/10
7205759403792793
因此,56是N的唯一可能值,正好为J保留53位。因此,J的最佳可能值是这个商,四舍五入:
>>> q, r = divmod (2 ** 56, 10)
>>> r
6
由于进位大于10的一半,通过四舍五入获得最佳近似值:
>>> q + 1
7205759403792794
因此,“IEEE-754双精度”中1/10的最佳近似值为2**56以上,即:
7205759403792794/72057594037927936
注意,由于四舍五入是向上进行的,结果实际上略大于1/10;如果我们没有四舍五入,这个商会略小于1/10。但无论如何都不是1/10!
因此,计算机从未“看到”1/10:它看到的是上面给出的精确分数,这是使用“IEEE-754”中的双精度浮点数的最佳近似值:
>>>. 1 * 2 ** 56
7205759403792794.0
如果我们将这个分数乘以10**30,我们可以观察到这些值它的30位小数具有很强的权重。
>>> 7205759403792794 * 10 ** 30 // 2 ** 56
100000000000000005551115123125L
这意味着存储在计算机中的精确值近似等于十进制值0.100000000000000005551115123125。在Python 2.7和Python 3.1之前的版本中,Python舍入这些值到17位有效小数,显示“0.10000000000000001”。在当前版本的Python中,显示的值是分数尽可能短的值,当转换回二进制时,给出的表示形式完全相同,只需显示“0.1”。
为了好玩,我按照标准C99的定义玩了浮点数的表示,并编写了下面的代码。
代码以3个独立的组打印浮点的二进制表示
SIGN EXPONENT FRACTION
然后,它打印一个和,当以足够的精度求和时,它将显示硬件中真正存在的值。
因此,当你写float x=999…时,编译器会将该数字转换为函数xx打印的位表示,这样函数yy打印的和就等于给定的数字。
事实上,这个总数只是一个近似值。对于数字999999999,编译器将在浮点的位表示中插入数字1000000000
代码之后,我附加了一个控制台会话,在该会话中,我计算硬件中真正存在的两个常量(减去PI和999999999)的项和,并由编译器插入其中。
#include <stdio.h>
#include <limits.h>
void
xx(float *x)
{
unsigned char i = sizeof(*x)*CHAR_BIT-1;
do {
switch (i) {
case 31:
printf("sign:");
break;
case 30:
printf("exponent:");
break;
case 23:
printf("fraction:");
break;
}
char b=(*(unsigned long long*)x&((unsigned long long)1<<i))!=0;
printf("%d ", b);
} while (i--);
printf("\n");
}
void
yy(float a)
{
int sign=!(*(unsigned long long*)&a&((unsigned long long)1<<31));
int fraction = ((1<<23)-1)&(*(int*)&a);
int exponent = (255&((*(int*)&a)>>23))-127;
printf(sign?"positive" " ( 1+":"negative" " ( 1+");
unsigned int i = 1<<22;
unsigned int j = 1;
do {
char b=(fraction&i)!=0;
b&&(printf("1/(%d) %c", 1<<j, (fraction&(i-1))?'+':')' ), 0);
} while (j++, i>>=1);
printf("*2^%d", exponent);
printf("\n");
}
void
main()
{
float x=-3.14;
float y=999999999;
printf("%lu\n", sizeof(x));
xx(&x);
xx(&y);
yy(x);
yy(y);
}
这里是一个控制台会话,我在其中计算硬件中存在的浮点值的实际值。我使用bc打印主程序输出的项的总和。可以将该和插入python-repl或类似的内容中。
-- .../terra1/stub
@ qemacs f.c
-- .../terra1/stub
@ gcc f.c
-- .../terra1/stub
@ ./a.out
sign:1 exponent:1 0 0 0 0 0 0 fraction:0 1 0 0 1 0 0 0 1 1 1 1 0 1 0 1 1 1 0 0 0 0 1 1
sign:0 exponent:1 0 0 1 1 1 0 fraction:0 1 1 0 1 1 1 0 0 1 1 0 1 0 1 1 0 0 1 0 1 0 0 0
negative ( 1+1/(2) +1/(16) +1/(256) +1/(512) +1/(1024) +1/(2048) +1/(8192) +1/(32768) +1/(65536) +1/(131072) +1/(4194304) +1/(8388608) )*2^1
positive ( 1+1/(2) +1/(4) +1/(16) +1/(32) +1/(64) +1/(512) +1/(1024) +1/(4096) +1/(16384) +1/(32768) +1/(262144) +1/(1048576) )*2^29
-- .../terra1/stub
@ bc
scale=15
( 1+1/(2) +1/(4) +1/(16) +1/(32) +1/(64) +1/(512) +1/(1024) +1/(4096) +1/(16384) +1/(32768) +1/(262144) +1/(1048576) )*2^29
999999999.999999446351872
就是这样。999999999的值实际上是
999999999.999999446351872
您也可以通过bc检查-3.14也受到干扰。不要忘记在bc中设置比例因子。
显示的金额是硬件内部的金额。通过计算它获得的值取决于设置的比例。我确实将比例因子设置为15。数学上,以无限的精度,它似乎是1000000000。