我在这里看到了各种答案,这些答案描述了C中pow
函数的奇怪行为。
但我在这里有不同的问题要问。
在下面的代码中,我初始化了int x=pow(10,2)
和int y=pow(10, n)
(int n=2)
。
在第一种情况下,当我打印结果时,它显示100
,在另一种情况下,它显示为99
。
我知道pow
返回double
并且它在存储在int
中时被截断,但我想问为什么输出会有所不同。
代码1
#include<stdio.h>
#include<math.h>
int main()
{
int n = 2;
int x;
int y;
x = pow(10,2); //Printing Gives Output 100
y = pow(10,n); //Printing Gives Output 99
printf("%d %d" , x , y);
}
输出:100 99
为什么输出结果会有所不同。?
我的gcc版本是4.9.2
更新:
代码2
int main()
{
int n = 2;
int x;
int y;
x = pow(10,2); //Printing Gives Output 100
y = pow(10,n); //Printing Gives Output 99
double k = pow(10,2);
double l = pow(10,n);
printf("%d %d\n" , x , y);
printf("%f %f\n" , k , l);
}
输出:100 99
100.000000 100.000000
更新CODE1的2个组装说明
使用gcc-S-masm=intel
生成GCC4.9.2的程序集说明:
.LC1:
.ascii "%d %d\0"
.text
.globl _main
.def _main; .scl 2; .type 32; .endef
_main:
push ebp
mov ebp, esp
and esp, -16
sub esp, 48
call ___main
mov DWORD PTR [esp+44], 2
mov DWORD PTR [esp+40], 100 //Concerned Line
fild DWORD PTR [esp+44]
fstp QWORD PTR [esp+8]
fld QWORD PTR LC0
fstp QWORD PTR [esp]
call _pow //Concerned Line
fnstcw WORD PTR [esp+30]
movzx eax, WORD PTR [esp+30]
mov ah, 12
mov WORD PTR [esp+28], ax
fldcw WORD PTR [esp+28]
fistp DWORD PTR [esp+36]
fldcw WORD PTR [esp+30]
mov eax, DWORD PTR [esp+36]
mov DWORD PTR [esp+8], eax
mov eax, DWORD PTR [esp+40]
mov DWORD PTR [esp+4], eax
mov DWORD PTR [esp], OFFSET FLAT:LC1
call _printf
leave
ret
.section .rdata,"dr"
.align 8
LC0:
.long 0
.long 1076101120
.ident "GCC: (tdm-1) 4.9.2"
.def _pow; .scl 2; .type 32; .endef
.def _printf; .scl 2; .type 32; .endef
我知道pow返回双精度,并且它在存储在int中时被截断,但我想问为什么输出会有所不同。
你必须首先,如果你还没有,摆脱浮点数在任何方面都是合理或可预测的想法。double
只近似实数,你用double
做的几乎任何事情都可能是实际结果的近似。
也就是说,正如你已经意识到的,pow(10, n)
产生了一个像99.99999999999997
这样的值,这是一个精确到15个有效数字的近似值。然后你告诉它截断到小于这个数的最大整数,所以它扔掉了大部分。
(旁白:很少有很好的理由将double
转换为int
。通常你应该使用sprintf("%.0f", x)
之类的东西来格式化它以进行显示,它可以正确舍入,或者使用地板
函数,它可以处理可能超出int
范围的浮点数。如果这两者都不适合你的目的,比如在货币或日期计算中,你可能根本不应该使用浮点数。)
这里有两件奇怪的事情。首先,为什么pow(10, n)
不准确?10、2和100都可以精确地表示为double
。我能提供的最好答案是,你使用的C标准库有一个bug。(编译器和标准库,我假设是gcc和glibc,是根据不同的发布计划和由不同的团队开发的。如果pow
返回不准确的结果,那可能是glibc的bug,而不是gcc。)
在对你的问题的评论中,amdn发现了一个与FP四舍五入有关的glibcbug,这可能与另一个Q有关
(也可以想象,尽管不太可能,你的处理器的FPU是错误的。)
其次,为什么pow(10, n)
与pow(10,2)
不同?这个要简单得多。gcc优化了可以在编译时计算结果的函数调用,因此pow(10,2)
几乎可以肯定被优化为100.0
。如果您查看生成的汇编代码,您会发现只有一次对pow
的调用。
GCC手册第6.59节描述了哪些标准库函数可以这样处理(点击完整列表的链接):
其余功能用于优化目的。
除了具有库等价物(如下面讨论的标准C库函数)或扩展到库调用的内置函数之外,GCC内置函数始终是内联扩展的,因此没有相应的入口点,并且无法获得它们的地址。尝试在函数调用以外的表达式中使用它们会导致编译时错误。
[...]
ISOC90函数abort, abs,acos,asin,atan2,atan,calloc,ceil,cosh,cos,出口,exp,fabs,地板,fmod,fprintf,fput,frexp,fscanf,isalnum,isalpha,iscntrl,isdigit,isgraph,islower,isprint,issptt,isspace,istop,isxdigit,tolower,touch pper,labs,ldexp,log10,log,malloc,memchr,memcmp,memcpy,memset,modf,pow,printf,putchar,put,scanf,sinh,sin,snprintf,sprintf,sqrt,sscanf,strcat,strchr,strcmp,strcpy,strcspn,strlen,strncat,strncmp,strncmp,strncpy,strncpy,strncpy,strpbrk,strrchr,str-fno-builtin-function
为单个函数指定)。
因此,您似乎可以使用-fno-builtin-pow
禁用此行为。
为什么输出结果不同。?(在更新的附加代码中)
我们不知道价值观有那么大的不同。
当比较int/double
的文本时,请务必以足够的精度打印double
,以查看它是100.000000
还是靠近100.000000
或十六进制以消除所有疑问。
printf("%d %d\n" , x , y);
// printf("%f %f\n" , k , l);
// Is it the FP number just less than 100?
printf("%.17e %.17e\n" , k , l); // maybe 9.99999999999999858e+01
printf("%a %a\n" , k , l); // maybe 0x1.8ffffffffffff0000p+6
为什么输出会有所不同。?(在原始代码中)
C没有指定大多数的准确性
// Higher quality functions return 100.0
pow(10,2) --> 100.0
// Lower quality and/or faster one may return nearby results
pow(10,2) --> 100.0000000000000142...
pow(10,2) --> 99.9999999999999857...
将浮点数(FP)分配给int
简单地删除分数,无论分数与1.0有多接近
当将FP转换为整数时,更好地控制转换和舍入以应对微小的计算差异。
// long int lround(double x);
long i = lround(pow(10.0,2.0));
你不是第一个发现这个的人。这是2013年的讨论形式:pow()强制转换为整数,意外结果
我推测tcc人生成的汇编代码导致第二个值在计算完一个非常接近100的结果后被四舍五入。就像米基乔夫在那篇历史性的文章中所说的,看起来bug已经修复了。