mpz_limbs interface

[Torbjorn Granlund]

nisse at 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