> Date: Tue, 28 Nov 2017 05:32:45 +0700 > From: Robert Elz <k...@munnari.oz.au> > > Way back when I first learned floating point programming (something I > have done astonishingly little of in the intervening decades) I was > told it was *always* wrong to compare floats for exact equality - but > of course, that was back in the days when almost all computing was > numerical (simultaneous equation solfving, ffts, ...) and almost all > written in fortran (the only language worthy of using) ...
That's sensible advice for most questions that a numerical algorithm is likely to want to ask in the course of its computation, and when the operations you're performing do not have 0.5 ulp error bounds. (As general advice, usually you want to use relative error, namely |actual - expected|/expected, not absolute error, |actual - expected|, but that's an side.) However, in this case, we are testing the map from a decimal expansion to a floating-point number. Under IEEE 754-2008, this operation is required to be correctly rounded for decimal expansions of up to 20 significant digits (Sec. 5.12.2 `Details of conversion between floating-point data and external character sequences', pp. 31--32). Since every number here has 11 significant digits, the result must be identical from the compiler and from strtod unless one or the other is buggy. Can you please put it back to an exact equality test and report the mismatched values in the output, with %a rather than (or in addition to) %g so that we can see the precise difference in their bits when the test fails?
