Andrei Alexandrescu wrote:
On 10/20/10 5:32 CDT, Lars T. Kyllingstad wrote:
(This message was originally meant for the Phobos mailing list, but for
some reason I am currently unable to send messages to it*. Anyway, it's
probably worth making others aware of this as well.)
In my code, and in unittests in particular, I use std.math.approxEqual()
a lot to check the results of various computations. If I expect my
result to be correct to within ten significant digits, say, I'd write
assert (approxEqual(result, expected, 1e-10));
Since results often span several orders of magnitude, I usually don't
care about the absolute error, so I just leave it unspecified. So far,
so good, right?
NO!
I just discovered today that the default value for approxEqual's default
absolute tolerance is 1e-5, and not zero as one would expect. This
means that the following, quite unexpectedly, succeeds:
assert (approxEqual(1e-10, 1e-20, 0.1));
This seems completely illogical to me, and I think it should be fixed
ASAP. Any objections?
I wonder what would be a sensible default. If the default for absolute
error is zero, then you'd have an equally odd behavior for very small
numbers (and most notably zero). Essentially nothing would be
approximately zero.
Andrei
I don't think it's possible to have a sensible default for absolute
tolerance, because you never know what scale is important. You can do a
default for relative tolerance, because floating point numbers work that
way (eg, you can say they're equal if they differ in only the last 4
bits, or if half of the mantissa bits are equal).
I would even think that the acceptable relative error is almost always
known at compile time, but the absolute error may not be.
