Closed LeslieGreenCEngMIEE closed 2 years ago
Not a known bug as far as I am aware. I'll look into it.
Interestingly, mpz_pow_ui also fails the same test in the same way.
`typedef unsigned long long i64;
void main(){
mpz_t fermatNumber1;
mpz_init(fermatNumber1);
mpz_t two;
mpz_init_set_ui( two, 2);
...
for( int F = 30; F < 34; F++ ){
i64 n = ( 0x01LL << F ); // long long int constant keeps the compiler quiet.
mpz_pow_ui(fermatNumber1, two, n); // this one also doesn't work at F32
//mpz_ui_pow_ui(fermatNumber1, 2, n); // doesn't work for F32 or greater
mpz_add_ui(fermatNumber1, fermatNumber1, 1); // only now is this the Fermat Number
`
That is not surprising since I wouldn't expect these two functions to be different in their handling of their third argument.
This is a bug, which I have now fixed. Thanks for reporting it.
I pulled the changed file and can confirm that both the mpz-pow_ui and the mpz_ui_pow_ui variants are now fixed :-)
Your service is much appreciated.
It is unclear if this is a known MPIR problem on Win64. It seems as if the 3rd function argument in an unsigned long rather than an mpir_ui. Hence it doesn't work as advertised on Win64.
Example code: '
include "stdafx.h"
} ` ( Why the GitHub "code" tags are not working correctly on all the code is another mystery!)
Example output:
( I deleted the hash symbols in front of the Fermat Number indexes because they got converted to links )
I don't imagine that it is relevant, but MPIR was compiled as a K8/K10/K102 x64 release DLL for Windows 10, running on an AMD A10-7800 Radeon R7. All the MPIR tests ran correctly. The same DLL/test code also gives the same result on a Xeon E5-1650 v4 processor.