Bug #3365
closed
floats revisited (see bug 1841)
Description
=begin
someone posted that the float errors were just fine by them, referring to IEEE 754. I suggest visiting that standard yourself before closing the bug. If you look at the bug as reported, there is a rounding error on the 16th digit. IEEE 754 provides precision through 16 digits on doubles (binary64), the first rounding (eg, error) can only occur at the 17th digit.
I can confirm on my system that C does not produce the same results as ruby in this regard:
bash$ gcc -o fp fp.c && ./fp && ruby -e 'puts "\nfp.c\n······\n"' && cat fp.c && ruby -e 'puts "\nruby #{RUBY_VERSION}: #{100.0 - 91.6}"'
System double representaiton: 8.400000e+00
8.40000000000000568434188608080148696899414062500000e+00
8.40000000000000568434188608080148696899414062500000e+00
sizeof doubles 8
sizeof long doubles 16
fp.c
······
#include <stdio.h>
#include <math.h>
int main(){
double cien = 100.0;
double frac = 91.6;
long double ciento = 100.0;
long double fract = 91.6;
printf("System double representaiton: %e\n", cien - frac);
printf("%.50e\n", cien - frac);
printf("%.50Le\n", ciento - fract);
printf("sizeof doubles %d\n", sizeof(cien));
printf("sizeof long doubles %d\n", sizeof(ciento));
return 0;
}
ruby 1.9.1: 8.40000000000001
independently of whether ruby would or would not conform to IEEE754 the fact that C does not see doubles the same as ruby can be seen as a bug. as can the fact that right now elementary math any 2nd grader could expect to use with ruby can fail (100.0 - 91.6 == 8.4).
=end
Updated by 
Updated by