Re: question about result from mpz_ModPow

Marco Bodrato bodrato at anjara.org
Sun Aug 16 11:08:52 CEST 2026


Ciao,

Il giorno Domenica, Agosto 02, 2026 15:55 CEST, rich beck <rich.beck at sbcglobal.net> ha scritto:

 
the runtimes of the mpz_ModPow function are MUCH faster than what I am
seeing with native BigInteger.ModPow function calls made directly in
VB.net, thank you!
 
Great!
 
When I run the following ModPow problem:

result = 3 ^ (prime-1)/2 MOD prime, where prime=329 x 2^4193199 +1,
and 3 is a primitive root of the prime.

The result should be the totient, (or (prime-1)) but i am not getting
that result in GMP.
 
How did you write the test with GMP?
 
All other tests i run with primes <= 2M-bits in length work fine and
return expected results of (prime-1) using the GMPBridge.h code as the
bridge between GNU and VB.net.

Is there an implicit or undocumented string length in arguments that
I am exceeding when I test with this HUGE prime number?
 
I'd not use strings for such a computation.
So, I do not understand the question.
 
I would like to test one additional candidate NTT_Prime:
31 x 2^8348000 +1, also using 3 as the primitive root,
 
It's not too hard to write a program that can test such a prime.
But remember: but the larger, the slower…
 
and use GNU/GMP to do this. BigInteger.ModPow can not process this, and
am hoping that GNU/GMP can handle this size prime, but there appears
to be an argument length limit of roughly 2M-bits.
 
It can handle this size, but it will take a lot of time :-)
The number of bits in an mpz_t must fit an unsigned long.
On Windows that's 32-bits, it means that with GMP you can handle operands of size 4000M-bits.
During exponentiation, squaring is used, so the limit might be around 2000M-bits
 
Maybe the limit you see is on the VB side or due to the VB-GMP interface.
Therefore, gmp-bugs is not the right list for this message.
 
Ĝis,
m


More information about the gmp-bugs mailing list