[Bug math/28472] pow(10, i) accuracy

["newbie-02 at gmx dot de" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28472

--- Comment #8 from b. <newbie-02 at gmx dot de> ---

are the following differences based on any reasonable idea? is it of help to
dig down this issue?  

printf( "%.25E\n", pow( 10, 23 ) );  -> 9.9999999999999991611392000E+22  

in contrast to:  
int j = 23;  
printf( "%.25E\n", pow( 10, j ) );   -> 1.0000000000000000838860800E+23  

IMHO the results should match!  

same with 210:  

printf( "%.25E\n", pow( 10, 210 ) ); -> 9.9999999999999992711378242E+209  

while:  

j = 210;  
printf( "%.25E\n", pow( 10, j ) );   -> 1.0000000000000000731118822E+210  

seems independent of j defined as integer or double, and constants written as
'x' or 'x.0', but dependent on compiler options:  

no '-Ox' option set or '-O0': above differences,  
'-O1', '-O2' or '-O3' set   : results match, all 9.99999xxx,  

different evaluation at compile- vs. runtime? I seem to remember similar
oddities when a compiler replaces long double constants with doubles at compile
time????  

but why here? me in error? me stupid, me blackout? or is gcc / glibc / ???
kidding with the programmers?  

admit to be confused, esp. about this error being dependent on compiler
options,  while the test program by M Welinder, and gnumeric where the problem
first came up, are not.

-- 
You are receiving this mail because:
You are on the CC list for the bug.