Very true. However, in the case of the new sqrt(), the fast version
should be good about this, including the special cases (negative
numbers, NaNs, +-Inf etc). It should also be exact (ie conform to IEEE,
with the result being the "optimally" close result given the precision
of IEEE doubles).
The only thing it doesn't do is give the IEEE "inexact" result (ie tell
when the result is _really_ the exact result, and when it's just the
approximation that fits in a double).
No, I haven't proven my routine mathematically, but I _did_ start from a
mathematically correct algorithm, and as far as I can tell my
implementation _should_ be a correct implementation of that algorithm.
My test-program certainly gave the expected error-results.
In short: it's very easy to create a fast function that doesn't work
according to specs, but at least in the case of this sqrt() function
that shouldn't be a problem.
(And everybody _knows_ that I always write perfect code, so you don't
even need to double-check, right? Sure)
Linus