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