mpz_limbs interface

[Niels Möller]

Torbjorn Granlund <tg at gmplib.org> writes:

> I'm to busy to make an educated analysis.

I understand. And maybe this should wait, since we're close to release,
and it's not entirely trivial to get the interface right. My original
motivation was that with the new mpz_limbs_* interface, mpn_set_d seemed
to be one of the last missing functions to be able to get mpfr to use
documented gmp functions exclusively.

> Why isn't __gmp_extract_double's style OK for mpn_set_d?  Is its
> conventions not neat enough, or are there efficiency reasons?

I found the conventions of __gmp_extract_double hard to understand. And
I think returning a base 2 exponent is more consistent with mpn_get_d.

I haven't thought very much about efficiency. Note that the spec leaves
some freedom to the implementation. E.g., if it's desirable in all (or
most) cases to return an exponent that is a multiple of GMP_NUMB_BITS,
that could be implemented.

> Do you plan to replace __gmp_extract_double by mpn_set_d where
> __gmp_extract_double is used currently? 

If we add mpn_set_d, we should definitely use it internally and retire
__gmp_extract_double. I haven't examined all uses, but they are not
many: mpf_set_d, mpf_cmp_d, mpz_set_d, mpz_cmp_d, mpz_cmpabs_d,
mpq_set_d.

> Keeping both these two very similar functions seems a bit ugly.

Agreed. We should design mpn_set_d so that it is able to replace
__gmp_extract_double.

/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.