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