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

Marc Glisse <marc.gli...@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
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel

Reply via email to