mini-gmp mpz_{get,set}_d not fully compatible with GMP

Marc Glisse marc.glisse at inria.fr
Tue Mar 6 22:58:11 UTC 2018


On Tue, 6 Mar 2018, Niels Möller wrote:

> Marc Glisse <marc.glisse at inria.fr> writes:
>
>> On Tue, 6 Mar 2018, Marco Bodrato wrote:
>>
>>> Which solutions do you suggest? I see 3 possible ways:
>>> - removing the non "fully compatible" functions;
>>> - adding them to the "with a few exceptions:" section;
>>> - correct the behaviour of the functions...
>>
>> As discussed for instance last October, the generic, non-IEEE version
>> of mpn_get_d has a similar issue. Maybe they could both be fixed at
>> the same time with the same code?
>
> For mini-gmp, it's highly desirable for the get_d function to be fully
> compatible with gmp at least for the common case of standard IEEE
> floats. I'm fine with documenting different behavior for obscure
> floating point variants.
>
> For GMP, it's desirable to fix also the non IEEE-version.
>
> Can we rely on FLT_RADIX and DBL_MANT_DIG (float.h, see
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/float.h.html),
> to get correct rounding at least as long as FLT_RADIX == 2 ?

The code shouldn't be too hard to write using count_leading_zeros and 
DBL_MANT_DIG, but I have no idea how many platforms are missing 
DBL_MANT_DIG. I am not really interested in such platforms...

> If I recall earlier discussion correctly, we really need to know the
> size of the mantissa, from the compiler or a configure check (and the
> latter is not applicable to mini-gmp).

It is also possible to determine it at runtime (comparing 2^n+{0,1,2} for 
instance should work whether we round up, down or to the nearest; 
tests/misc.c compares 2^n+1-2^n to 1, which also looks good), doing it 
once and storing the result somewhere.

-- 
Marc Glisse


More information about the gmp-devel mailing list