ni...@lysator.liu.se (Niels Möller) writes: > 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. Such consistency has some value.
But not to the price of slowdown for set_d and cmp_d function. 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. Perhaps it would be worth modifying one or two of these, and see if the total executed code is comparable or better than currently. LIMBS_PER_DOUBLE values might no longer be relevant if the exponent is bits. As long as 2 * GMP_NUMB_BITS >= 53 (for IEEE 754) then at most two limbs will be needed. Similarly, if GMP_NUMB_BITS > 53 just one limb is needed. And at least for normalised input, no shifting should be needed. The function should become almost trivial, just store in the 'extract' union's double field, and them load of one ot two limbs. But then the shifting done in __gmp_extract_double will be needed in every caller. Or am I mistaken? __gmp_extract_double's main job today is exactly "limbification". Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel