Thread: Mlucas v19 available View Single Post
2021-02-01, 20:37   #90
ewmayer
2ω=0

Sep 2002
República de California

7×11×151 Posts

A ha ha, I'm such an idiot - let's again look at your example '-s h' self-test error message:
Quote:
 Originally Posted by tdulcet Res mod 2^35 - 1 = 7270151463 Res mod 2^36 - 1 = 68679090081 *** Res35m1 Error *** current = 7270151463 should be = 29128713056 *** Res36m1 Error *** current = 68679090081 should be = 7270151463 -- Return with code ERR_INCORRECT_RES64 Error detected - this radix set will not be used. WARNING: 0 of 10 radix-sets at FFT length 65536 K passed - skipping it. PLEASE CHECK YOUR BUILD OPTIONS.
Notice that the 'current' (= from self-test) Res35m1 value matches the 'should be' (= pretabulated reference value) Res36m1 one? Let's have a look at the pretabulated reference residues for this FFT length in Mlucas.c:

{ 65536,1166083297u, { {0xA0FE3066C834E360ull, 29128713056ull, 7270151463ull}, ...

65536K FFT, reference test exponent 1166083297, followed by 3 ref-residue triplets, corresponding to the test residue modulo 2^64 (low 64 bits of full residue = Res64, in hex), 2^35-1 and 2^36-1. The triplets are for -iters 100,1000,10000, I have copied only the 100-iter one above.

The residues modulo 2^35-1 and 2^36-1 are a.k.a. the Selfridge-Hurwitz residues, after the 2 worthies who used them for their Fermat-number primality-testing work in the 1960s, on mainframe hardware which supported a 36-bit integer type. They also included the residue modulo 2^36, but as that is just the low 36 bits of the GIMPS-used Res64, it's redundant. But until a couple years ago, Mlucas would print all 4 residues like so - let's again use the above case to illustrate, since we can trivially extract the Res36 from the Res64:
Code:
Res64: 0xA0FE3066C834E360
Res mod 2^36     = 29128713056
Res mod 2^35 - 1 = 7270151463
Res mod 2^36 - 1 = 68679090081
Now it's clear what must've happened - a few years back when I tabulated those '-s h' entries, I must've done all the needed runs, assembled the resulting 4-line entries as above, then batch-edited them. Should've deleted the Res mod 2^36 line and used the remaining 3, but must've instead kept the first 2 decimal residues and deleted the the mod 2^36 - 1 one in a bunch of cases.

The good news is that that makes it easy to see which tabulated entries are fubar in this manner - just extract the low 9 hexits of the Res64 for each triplet, print in decimal, see if that matches the first of the 2 following 36-bit decimal entries in the triplet, if so, it's fubar.

Per that, for the 100-iter triplets, all but last 3 need redo - but those 3, for FFT lengths 212992,229376,245760 - should be OK. Further, none of the 1000-iter reference triplets show the above 'whoops', so those should all be OK.

But I see I never got around to filling in the 10000-iter table entries for these large FFT lengths, so since the 100 and 1000-iter are pretty fast to recompute compared to those, gonna redo them all.