best way to get mantissa from mpf_t

[Torbjorn Granlund]

Paul Zimmermann <Paul.Zimmermann at loria.fr> writes:

         Chris,
  
  > From: "Rev. Chris Korda" <victimofleisure at gmail.com>
  > Date: Wed, 3 Dec 2008 19:21:50 -0500
  > 
  > My friend and I are developing fixed-point functions to accelerate squaring
  > and adding/subtracting for a fractal explorer. The explorer uses mpf_t for
  > navigation, so we need to convert from mpf_t to fixed-point. We're currently
  > obtaining the mantissa by using mpf_get_str to convert to a hex string, and
  > then converting the hex into binary words. Is this a reasonable approach, or
  > is there something better? Should we convert to mpn_t first? We also need to
  > convert back the other way (from fixed-point to mpf_t) but we haven't
  > started working on that yet.
  > 
  > Best regards,
  > 
  > Chris
  > http://fractice.sourceforge.net/
  
  your approach is not the best possible. In mpf, the significand is stored in
  base W, where W is the base word (2^32 or 2^64). Thus the fixed-point is
  directly available from the significand, which is an array of limbs.
  For example, the number sqrt(2) might be stored on a 64-bit computer as two
  limbs, the most significant limb being a[0]=1, and the least significant limb
  being a[-1]=7640891576956012809. The corresponding value is sum(a[i]*W^i).
  As a consequence, you can transform the significand into a fixed point value
  by a simple shift (mpn_rshift) or even no operation at all if your "point"
  corresponds to some W^k.
  
One could almost think you're recommending people to rely on internal
fields and their interpretation!  :-)

For GMP 4.3, I will rename _mp_d to _mp_size and _mp_size to _mp_d, so
any code that plays with GMP internals will be duly punished.

Seriously, I will rename some fields in 4.3, with the hope that I get
feedback from those who depend on internals, since such usages suggest
weaknesses of GMP's interface.  I'd like to address those weaknesses.

For GMP 5, the fields usage will actually change somewhat, in order to
support larger numbers.  It would be good to have discouraged the
dependency of user code on internals before that change!

-- 
Torbjörn