[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
## Re: mpz_sizeinbase

**From**: |
Kevin Ryde |

**Subject**: |
Re: mpz_sizeinbase |

**Date**: |
29 Mar 2001 08:06:57 +1000 |

**User-agent**: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.5 |

"Winfried Dreckmann" <address@hidden> writes:
>* *
>* I have a problem with the source code for "mpz_sizeinbase" in gmp 3.1.1.*
>* If the base is not a power of 2 it calculates its result by the*
>* following expression:*
>* *
>* return (size_t) (totbits * __mp_bases[base].chars_per_bit_exactly) + 1;*
>* *
>* Here "totbits" is the number of significant bits and*
>* "__mp_bases[base].chars_per_bit_exactly" an approximation of the*
>* logarithm of 2 in the given base. Due to limited precision there is no*
>* garantuee that this result is actually greater than the true*
>* mathematical logarithm. As a consequence is may happen for very, very*
>* large numbers that the result is 1 too small. (The manual states that*
>* the result is exact or 1 too big.)*
Well, there should be 53 bits of precision on that log, which should
be enough.
>* Using the gmp approximation:*
>* *
>* 198096465 * 0.3010299956639811 = 59632977.99999998373681149999*
I'm unable to reproduce that on a ppc604e (or an i386), I get ...78 as
expected. Is the compiler giving the right value for chars_per_bit?
printf ("%A\n", __mp_bases[10].chars_per_bit_exactly);
should print 0X1.34413509F79FFP-2 by my reckoning.
But your point is taken though, it'd be better not to depend on
floating point for this. A fixed point integer approximation would
make it easier to guarantee the results, and would also hopefully make
it possible to address the problem with 64-bit mpf exponents noted in
doc/tasks.html.

**mpz_sizeinbase**, *Winfried Dreckmann*, `2001/03/27`
**Re: mpz_sizeinbase**,
*Kevin Ryde* **<=**