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