From: Eli Z. <el...@gn...> - 2013-12-08 16:46:35
|
> From: <sis...@op...> > Date: Mon, 9 Dec 2013 00:14:59 +1100 > > For the double precision value '95e20', on mingw.org ports of gcc-3.4.5 and > 4.7.0, I find that > > double d = 95e20; > and > double d = strtod("95e20", NULL); > > assign different values to the variable "d". GCC might use something other than strtod to convert double literals. E.g., latest versions of GCC are linked against MPFR, right? > int main(void) { > double d1 = 95e20, d2; > > d2 = strtod("95e20", NULL); > > if(d1 == d2) printf("strtod works as expected\n"); > else printf("strtod seems to be buggy\n"); As Keith points out, you shouldn't compare floating-point numbers for equality. It is much better to display their difference, you might be surprised how insignificant it can be. In general, any difference that is less that machine epsilon relative to the value of either d1 or d2 is the usual roundup you should expect in FP calculations. > ############################## > strtod seems to be buggy > 9.500000000000001e+021 9.499999999999999e+021 > strtod seems to be buggy > 3.263787126000000e+019 3.263787126000000e+019 > strtod seems to be buggy > 1.464000000000000e+023 1.464000000000000e+023 > ############################## I see nothing unexpected in this output. > (The mpfr library reveals that it's the strtod() function that's producing > the incorrect value - and that assigning the values directly results in a > *correct* value.) A floating-point value is almost always "incorrect", because machine representation has finite precision and uses base-2 mantissa. > My questions: > Has this been fixed in the current mingw.org port of gcc-4.8.x ? Are you asking about GCC or about strtod? If the latter, that function comes from the MS library, not from GCC folks. Again, look at the difference, and then decide whether you really care. |