approxEqual() has fooled me for a long time...

[Andrei Alexandrescu]

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