Behavior of mpf_eq near zero

Alejandro Mallea janoma at
Tue Apr 14 02:22:50 UTC 2015

Thank you all for your answers. I will take a look at MPFR and, in the
meantime, I will be using some comparison of the form
"abs(a-b)<epsilon". gmp_reldiff is useless to me because the
parameters are dynamic and could be exactly zero.

It's still surprising to me that this wasn't in the documentation. If
somebody is interested in my opinion, I would say the function should
be deprecated, since its very definition depends on the internal
representation instead of any arithmetic property inherent to the
values they represent.

By the way, should I be worried about finding similar behavoir rin MPFR?


On 13 April 2015 at 10:16, Vincent Lefevre <vincent at> wrote:
> On 2015-04-13 14:19:14 +0200, tg at wrote:
>> Vincent Lefevre <vincent at> 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> - Web: <>
> 100% accessible validated (X)HTML - Blog: <>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> _______________________________________________
> gmp-discuss mailing list
> gmp-discuss at

More information about the gmp-discuss mailing list