Base (2 to 62) limitation for set_str initialization and output

[Sergio Martin]

>
> Initialization is not done with a base (see
> http://gmplib.org/manual/Initializing-Integers.html). mpz_inp_raw() and
> mpz_out_raw() are exactly what you are looking for:
>
>
Yes, indeed they are what I was looking for. As I said in my response to
Torbjörn, the program I made to create a raw binary number was lacking the
4 bytes information regarding the size of the limb-bytes needed by the
mpz_inp_raw(). That's why I initially thought that it wasn't fit for my
requirement. However, adding a simple script to concatenate that info to
the file solves the original problem.

I'm honestly curious as to what space you are hoping to spare. I did some
> math:
>
> One 4096-bit number takes 688 base-62 digits, or 512 base-256 digits, a
> savings of 176 bytes. One million of these numbers would save you a grand
> total of 176 MB.
>
> One 1048576-bit number takes 176107 base-62 digits, or 131072 base-256
> digits, a savings of 45,035 bytes. One million of these numbers would
> saving you a grand total of 45 GB when using mpz_out_raw instead of
> mpz_out_str.
>
> I did the math with the gmp gem in Ruby:
>
> $ irb -r gmp --simple-prompt
> >> GMP::F(2**4096).log / GMP::F(62).log
> => 0.68791819860804378e+3
> >> GMP::F(2**4096).log / GMP::F(256).log
> => 0.51200000000000000e+3
> >> GMP::F(2**1048576).log / GMP::F(62).log
> => 0.17610705884365921e+6
> >> GMP::F(2**1048576).log / GMP::F(256).log
> => 0.13107200000000000e+6
> >> 176107 - 131072
> => 45035
>
>
Yes, I was careless about estimating the space savings of using a raw
binary number instead of the base 62 representation. Both you and Torbjörn
corrected me in this aspect.

However marginal the saving might be, it is still important for what I'm
currently studying.

Thank you too for your response, Sam.

Sergio Martin