nisse at lysator.liu.se
Thu Feb 6 19:58:23 UTC 2014
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,
> 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
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-devel