Behavior of mpf_eq near zero

[Vincent Lefevre]

On 2015-04-13 14:19:14 +0200, tg at gmplib.org wrote:
> Vincent Lefevre <vincent at vinc17.net> writes:
> 
>   The manual poorly specifies this function since it doesn't say what
>   the first bits of a number are. For instance, the first 3 bits of
>   
>     0.000
>   
>   and
>   
>     0.001
>   
>   are "0.00" thus are equal. So, you need to introduce the concept
>   of normalization, and possibly take zero apart since it cannot be
>   normalized.
>   
> I think that interpretation is a bit odd.  The same argument would make
> 17 and 4711 mpf_eq to 10 bits since these numbers are are 000000000010001
> and 00000000001001001100111...

Yes, and this is why the mpf_eq function is poorly specified. It seems
that it is said nowhere whether the mpf numbers are always normalized.
So, it is not clear whether 17 and 4711 could be regarded as equal by
mpf_eq in practice.

FYI, decimal numbers in IEEE 754-2008 are not automatically normalized
(automatic normalization in mainly interesting in radix 2 due to the
advantage of the implicit bit rule for the binary encoding, but mpf
doesn't even use radix 2).

>   > Please don't use this function.  At least use mpf_reldiff, or even
>   > better, use the mpfr GMP extension library.
>   
>   I agree, though I really think that mpf_eq should be properly
>   specified. And how about saying that this function is obsolete
>   and planning to remove it in the future?
> 
> I agree with the latter.  The function is broken, it has no reasonable
> mathematical interpretation.  (I take full responsibility for this, since
> I wrote it.)

Specially with my remark above.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)