Search for prime Gaussian-Mersenne norms (and G-M-cofactors)

[Batalov]

It is like mfaktc, e.g.
===worktodo.txt===
Factor=gm,4748941,1,60
================
On a GTX780, this test takes a minute, while on an i7 an equivalent test takes half an hour (with 62-bit limit, 4 minutes). It is not well tested yet. I've got tons of errors for p>5100000. (no errors below though) Need to debug.

I will make a portable version with George's tf_validate.h borrowed from mmff (+modified). Then it will be totally portable and will work for >64 bit factoring. I will post a working version of the code tomorrow. We will ask Jerry Flash Hallett to build a Win version.

[Citrix]

Thanks. I will wait for the exe.
I am sad that this is the third time I will have to sieve the same range (I took your advise and sieved my range to 60 bits before).

I will stop my computers in the meantime. I might be able to unreserve part of the range.. to keep up with the rule of finishing everything in 1 month.

[Batalov]

Hmm... found what was wrong with some of the factors that gmqfaktc was finding. (And why it was not a problem for mfaktc.)
I thought that it was a bug, but it is a feature.

mfaktc first sieves the factors with, say, 5000 small primes. (But this procedure let's some composites through. If we factor factors too deep, the GPU will be wasting time.)
For mfaktc this is not a problem - the composite is a product of some primes and all divide the Mp.

Now, in gmqfaktc, I check for factors of 2^(2p)+1 = 5*GM*GQ.
I get some factors from GPU, and then they are checked on CPU and some divide GM and some divide GQ (all factors are > 5).
So, I was getting some factors that divide neither (!).
And now I checked them -- they are composite, say, p*q, where
p divides GM and q divides GQ! So there was no real bug in CUDA code.
I don't want to reimplement a factoring subsystem inside the program and will just report that
"GM*GQ(p) has a factor : f".
For us, this means that this candidate can be dismissed right away (no luck on either side, no N-1/PRP test needed). If someone wants, they can factor f externally.

Now I need to add the George's code... hold on.

[Batalov]

I have another negative (not surprising) result pertaining to G/E-M/Fs.

Recall that Mike Oakes cataloged the interesting cases back in 2001, and one overlooked case is what he called Gaussian-Fermat primes and Eisenstein-Fermat primes. These are analogs of Fermat primes in Z, and as such one can expect them to have zero density (just a few initial primes and finita la comedia). Well, it doesn't hurt to try. Mike checked the Eisenstein-Fermat primes 3^2[SUP]n[/SUP] - 3^2[SUP]n-1[/SUP] + 1 up to n<=19 (for n<=1 the sign is plus, then minus). I factored EF for n=20,21,24,25,28,30 and now tested n=22 and 23. No primes. Next candidates are 3^2[SUP]26[/SUP] - 3^2[SUP]25[/SUP] + 1, and 3^2[SUP]27[/SUP] - 3^2[SUP]26[/SUP] + 1, if someone wants to have fun. (Note that factors of these have form k*2ⁿ⁺¹ + 1.)

Same can be tested for Gaussian-Fermat primes. Almost assuredly composite but it is a fun side project.

[Batalov]

Originally Posted by Citrix

Thanks. I will wait for the exe.
I am sad that this is the third time I will have to sieve the same range (I took your advise and sieved my range to 60 bits before).

I will stop my computers in the meantime. I might be able to unreserve part of the range.. to keep up with the rule of finishing everything in 1 month.

Updating status once a month, I think, was what Borys said. Everyone has their own pace and that's fine.

You should go on with tests as planned, - no need to stop N-1/PRP tests. If you don't have "1"s in the sieve files (their outputs should be kept), then you have nothing to worry about, really. When all tests are done, the final pass is performed - all primes (23172 in your interval) should be either in the sieve file (with validated factor: validation is instantaneous with gp) or in the residue file (1% can be run twice to feel confident about results). Logs should be grepped; every once in a while there is a rounding error > 0.40, but most often the next line says that this is reproducible and therefore not a hardware error. These few could be re-run optionally with higher FFT. This is like a mini-GIMPS* project only everything is in one hands (and not every tool is perfect but they almost are, just a little extra is needed).

________________
*speaking of replicating a mini-GI(G)MPS, I even tried P-1 but it was too tedious (and not too effective). Say, we want to eliminate a GM, and factors of GQ are already known. One can run P-1 on 2^2p+1 but all small factors (including 5) should be listed in the worktodo.txt for a Prime95 session; this can be automated with a bit of perl and sql.

[Batalov]

Ugh*. The attached source should build and hopefully will work.

I've tested it inasmuch that the ouput.c compiles on Windows (it has assembly-less mulmod replacement code, courtesy on JasonP, taken verbatim from msieve and slightly abridged). Everything else was tested on Linux.

Now, we'll need help from Flashjh (I will PM him). Jerry, please build as if it were mfaktc, and please post the win32 and win64 binaries (packaged as mfaktc was).

[Cruelty]

Congratulations!
Now, both me and Citrix have to finish our ranges and then we'll be quite sure it's GM39

[Batalov]

Update: for GMs, I have passed 5M.

I have left some GQ-only candidates behind (but they are done to 4.7M and there was a GQ at 4.5M); I will pull up that slack a bit later.


P.S. Jerry wrote that he will compile gmqfaktc tonight.

[flashjh]

Originally Posted by Batalov

Update: for GMs, I have passed 5M.

I have left some GQ-only candidates behind (but they are done to 4.7M and there was a GQ at 4.5M); I will pull up that slack a bit later.


P.S. Jerry wrote that he will compile gmqfaktc tonight.

Hello everyone LOL:

Originally Posted by Batalov

...We will ask Jerry Flash Hallett to build a Win version.

Attached Windows 32 & 64-bit binaries
CUDA 6.0 with SM 1.1,1.3,2.0,3.0,3.5, & 5.0.

Files are untested, but no code changes were required to compile. I had to use MSVS 2013 due to MSVS 2012 not recognizing 'strtoull'

[Batalov]

CUDA 6.0-pre. Uh-oh. Well, let's dive in, then.

EDIT: replace with strtoll() or whatever...
... or I can write in 10 seconds a short inline replacement, you know, like

    uint64_t b, c, f; int p, p2; char buf[128], *x;
    
    if(mystuff->mode != MODE_SELFTEST_SHORT)
    {
      if(mystuff->printmode == 1 && factor_number == 0)printf("\n");
      p2=((p=mystuff->exponent/2)-1)/2;
      for(f=0,x=factor;*x;x++) f=f*10ULL+(*x-'0');
      //f=strtoull(factor,NULL,10);

[flashjh]

I can try 5.5 again in the morning. I couldn't get 5.5 to compile but I think it was MSVS 2012 that was the problem.