mpf_out_raw, mpf_inp_raw chudpi2
cino hilliard
hillcino368 at hotmail.com
Thu Nov 29 18:06:11 CET 2007
> Today's Topics:
>
> 1. GUI (Jose de Jesus Angel Angel)
> 2. GMP on parallel computers (Marius Neagoe)
> 3. Chudnovsky, PiFast, etc (Jim White)
> 4. Re: GUI (Alexey Beshenov)
> 5. Re: GUI (Linas Vepstas)
>
> Message: 3
> Date: Wed, 28 Nov 2007 15:52:18 +0000 (GMT)
> From: Jim White
> Subject: Chudnovsky, PiFast, etc
> To: gmp-discuss at swox.com
> Message-ID:
> Content-Type: text/plain; charset=iso-8859-1
>
> RE: Improved timing for chudnovsky.c (cino hilliard)
>
>> What we do is multiply the mpf number by 10^digits.
>> This produces a big integer out of the mantissa.
>
> The mantissa already IS a big integer!
I was using the manual as my guide.
— Function: void mpz_set_f (mpz_t rop, mpf_t op)
Set the value of rop from op.
mpz_set_d, mpz_set_q and mpz_set_f truncate op to make it an integer
The mantissa is not an integer. If it were, the above function would do the
job I want to do and not return 0.
>From Wolfram:
Mantissa
For a real number , the mantissa is defined as the positive fractional part.
For example, for real 3.14159 , the mantissa is 0.14159.
>
> Think "power method" with scaling by 2 ^ size-in-bits.
I do not know what this means. Sorry.
>
>> My guess is the speed of this power method is the
>> result of low level optimization of the power
>> function performed in the compiler.
Looks like a bad guess from results below.
>
> I would suggest that this is simply the natural
> consequence of avoiding formatted output conversion
> (ie, radix conversion), and has nothing to do with the
> compiler at all.
Ok. I should have said the program code. The compiler is just a translator of the
program code into machine code amenable to the cpu that is expected to execute it.
Nevertheless, sometimes a compiler is coded to look for obvious things such as empty
loops in disguise and adjust the code accordingly to avoid processing it. Eg.,
for(x=0;x mpf_out_raw does no "conversion" work at all, so if
> you used that to write the result, this step should
> take no time at all (other than that dictated by the
> amount of data to be dumped)
Apparantly gmp handles arithmetic in base 256? This getting compressed files of
numbers baffles me. We may have a good encryption system here too.
If ascii had more characters, could we compress even more?
GMP Rocks.
Have fun,
Cino Hilliard
More information about the gmp-discuss
mailing list