[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mpz_sizeinbase
From: |
Winfried Dreckmann |
Subject: |
Re: mpz_sizeinbase |
Date: |
Thu, 29 Mar 2001 08:00:51 +0200 |
Kevin Ryde <address@hidden> writes:
> Well, there should be 53 bits of precision on that log, which should
> be enough.
..
> 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.
I get 0X1.34413509F79FDP-2 on my machine which I think explains the
issue. For some reason 2 of those 53 bits get lost. But even with 53
bits of precision I see no proof that the original problem cannot occur.
> 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.
The problem is that I want to use the function for a math library. So I
want it to be correct or, at least, know the range in which it is
correct.
Perhaps the following is helpful:
bash-2.03$ gcc -v
Reading specs from /usr/lib/gcc-lib/powerpc-suse-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
bash-2.03$ uname -a
Linux tohu 2.2.14 #1 Tue May 30 01:15:50 GMT 2000 ppc unknown
bash-2.03$ ./config.guess
powerpc-unknown-linux-gnu
processor 604e
clock 170MHz
revision 2.2
machine Power Macintosh
Winfried Dreckmann
- mpz_sizeinbase, Winfried Dreckmann, 2001/03/27
- Re: mpz_sizeinbase,
Winfried Dreckmann <=