Torbjorn Granlund <t...@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. _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel