Problem with large values in GMP...

[wraithx at morpheus.net]

On 3/17/2016 4:16 AM, Torbjörn Granlund wrote:
> Here is what I think is going on.
>
> The calculation of the expected result size of powering is not exact,
> but a slight over-estimate.  That't not easy to fix without messing
> around with very accurate logarithms.
>
> Furthermore, when using 64-bit ABIs which are LLP64 (like Windoze-64)
> the size calculation looks like it is prone to overflow.  On LP64 (as
> opposed to LLP64) machines, overflow can happen but only when asking for
> a calculation which will never fit in any computer's memory.
>
> Giving systems like Windoze-64 a slightly larger range for mpz is not a
> trivial task; it would require internal and externally visible typing
> changes.  E.g., the externally visible mp_bitcnt_t is supposed to hold
> the bitsize of any mpz number, and this type will become 32 bits under
> LLP64.  It is not clear how to type it without losing portability.
>
> Except for Windoze, LLP64 ABIs are fortunately rare these days.
>

So, would something similar happen during normal mpz_mul operations?  Here is 
the behavior I was originally trying to understand:

mpz_mul(num3, num1, num2)
num bits in num1 = 4006516961
num bits in num2 =  288450334
num bits in num3 = 4294967295

mpz_mul(num3, num1, num2)
num bits in num1 = 4006516961
num bits in num2 =  288450365
num bits in num3 =         30

I know there is probably a deep and/or complicated answer to this, but why not 
make mp_bitcnt_t (and mp_size_t, etc... ?) into the same type as mp_limb_t? 
What portability is lost by making this change?  Is it that you don't want to 
lose backwards compatibility with existing code bases?  Or that this change 
might cause subtle problems throughout the library that would have to all be 
fixed?  Or maybe something else?

I don't know if I could help much, but I'd be willing to test any changes or 
test versions.  Maybe I could try creating a local experimental copy of 6.1.0 
with these changes and seeing if I can get it to work?  I know this is a big 
library, so I'm probably (definitely?!) biting off more than I can chew.  I know 
that LLP64 systems are a kind of second class citizen, but I'd like to see it 
gain equal, or closer-to-equal, footing with LP64 systems.  Do you have any tips 
or hints of things that I should look for when making these changes?  Are there 
other types that I should expand?  Thanks again for making this great library 
and thanks for any help you can provide.

-David C.