gmp_printf bug?

[Torbjorn Granlund]

  I have convinced myself that we need to do away with the f-p table in
  mp_bases for good.  We rely on the host system's log function's
  exactness, which is fragile.  The numbers will be some ULP too small or
  some ULP too large, we know not.  I mpf/get_str.c, we need to carefully
  round up or down when using these precomputed values, the direction
  depends on the exponent of the number to be converted to a string.

  With integer (fractions) representing the logarithms, we get more
  adequate accuracy, and we can make them right to the last bit.  We can
  easily get rounding down (table the chopped log value, use umul_ppmm and
  extract high word).  Rounding up will be slightly tricker, using the
  chopped log value + 1 is not quite enough, if we chop the result product
  implicitly by taking the upper umul_ppmm word.

I went ahead and implemented log(2)/log(b) computation using functions
within dumbmp.c's ability.  Attached.  The code is simple enough.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: f.c
Type: application/octet-stream
Size: 1729 bytes
Desc: not available
URL: <http://gmplib.org/list-archives/gmp-devel/attachments/20110801/f2290178/attachment.obj>
-------------- next part --------------

The code is hardwired to compute 64-bit fractions for 2 <= b < 256.  The
goal is to compute floor((2^64)*log(2)/log(b)).

I hit a slight snag when attempting to put this into a GMP bootstrap; It
would take 8 hours to compute the 254 values using dumbmp.c, on the fast
GMP main development machine.  With GMP, it takes less than one second.
(A full GMP bootstrap on this machines takes about 30 seconds, meaning
this code would make for a quite noticeable slowdown.)

It seems dumbmp.c is dumber than I had expected.

Either we need to tweak dumbmp.c to do division (called from mpz_root)
faster, or, we need to include a accurate-enough table with the
distribution.  Creating a table for a particular build would then just
mean truncating the values to some shorter limb size.

-- 
Torbj?rn