On 10/20/10 16:33 CDT, Don wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
On 10/20/10 13:42 CDT, Walter Bright wrote:
Don wrote:
I'm personally pretty upset about the existence of that function at
all.
My very first contribution to D was a function for floating point
approximate equality, which I called approxEqual.
It gives equality in terms of number of bits. It gives correct results
in all the tricky special cases. Unlike a naive relative equality test
involving divisions, it doesn't fail for values near zero. (I _think_
that's the reason why people think you need an absolute equality test
as well).
And it's fast. No divisions, no poorly predictable branches.
I totally agree that a precision based on the number of bits, not the
magnitude, is the right approach.
I wonder, could that be also generalized for zero? I.e., if a number
is zero except for k bits in the mantissa.
Zero is a special case I'm not sure how to deal with.
It does generalize to zero.
Denormals have the first k bits in the mantissa set to zero. feqrel
automatically treats them as 'close to zero'. It just falls out of the
maths.
BTW if the processor has a "flush denormals to zero" mode, denormals
will compare exactly equal to zero.
So here's a plan of attack:
1. Keep feqrel. Clearly it's a useful primitive.
2. Find a more intuitive interface for feqrel, i.e. using decimal digits
for precision etc. The definition in std.math: "the number of mantissa
bits which are equal in x and y" loses 90% of the readership at the word
"mantissa". You want something intuitive that people can immediately
picture.
3. Define a good name for that
4. Decide on keeping or deprecating approxEqual depending on the
adoption of that new function.
Andrei
