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

Batalov · 2014-04-08, 06:18

Your binaries work fine, Jerry. Thanks from all of us!

In the meantime, I've got a full Studio 2012, uninstalled all 2013 mscrap, installed 2012, uninstalled CUDA5.5 (it was configured on the fly to not work, because "you have an unsupported version of the studio; only 2008, 2010, 2012 are supported", and that crap doesn't go away even after 2012 is installed), installed 6.0.

Testcase:
1. (I forgot to edit that into mfaktc.ini) change "SievePrimesMin=2000". This is because we are in a very low range in GMQs, still, compared to M.
2. Selftests (8 of them) pass; that's already good.
3. Use "Factor=gm,4748941,1,60" in worktodo.txt
4. Get this in results.txt:

Code:

(2^4748941-2^2374471+1)/5 has a factor : 1326550183177 [TF:1:60:mfaktc 0.20 75bit_mul32]
2^4748941+2^2374471+1 has a factor : 1401773408617 [TF:1:60:mfaktc 0.20 75bit_mul32]
found 2 factors for GM(Q)4748941 from 2^ 1 to 2^60 [mfaktc 0.20 75bit_mul32]

flashjh · 2014-04-08, 23:46

You're welcome. Do you still want CUDA 5.5 binaries?

Batalov · 2014-04-09, 00:41

They might be good for the people who would rather run it as they would mfaktc (with just libcudart64_55_....dll in the same directory; I don't know how volatile the libcudart64_60 will be). I probably will continue to run my linux binaries.

I have now restored my dev environment at home, too. (I've ~~lost~~ never reinstalled it after I'd moved from a well lived-in XP to Win7, and oh well I didn't have much to build recently; the mmff-gfn branch grew stable... Maybe I'll grow an extra limb to the mmff - and expand into higher n values for Fermat factoring, now. Unsure if I have time.)

P.S. I wrote the thing because I anticipated another long stretch to go for both G-M and E-M, but they both succumbed!

I, frankly, will wrap my search after I will finish the range that I reserved.
Warning: the new FFT size is imminent at or after 5.1M, too. The tests will be quite like watching the paint dry. Maybe a should start a new ~~sect~~ BOINC project. ;-)

flashjh · 2014-04-09, 01:44

Quote:

Originally Posted by Batalov

They might be good for the people who would rather run it as they would mfaktc (with just libcudart64_55_....dll in the same directory; I don't know how volatile the libcudart64_60 will be). I probably will continue to run my linux binaries.

I forgot all about the .dll file. If anyone need the CUDA 6 dll, let me know.

Quote:

The tests will be quite like watching the paint dry. Maybe a should start a new ~~sect~~ BOINC project. ;-)

It all seems to end up there. I stopped 'waiting' for the results a long time ago

I attached Windows binaries for CUDA 5.5 sm 1.1, 1.3, 2.0, 3.0, & 3.5

Untested with no changes to code. .ini in root is updated per the post above.

If anyone needs anything else, let me know.

EDIT: I just saw this post:

Quote:

Originally Posted by 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

Code:

    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);

When I use the MSVS 2013 environment it compiles fine. If anyone tries to use MSVS 2012 they'll need to make the change. My modified makefile.win and makefile.win32 files are included with the CUDA 6 and CUDA 5.5 files. ~~If you locate a copy of~~ If you use the included make.exe you can compile with MSVS 2013 with make -f makefile.win(32). Use 64-bit cmd windows for 64-bit and 32-bit cmd window for 32-bit. 32 bit requires the fixcc.bat file to be run inside the 32-bit cmd window.

Citrix · 2014-04-09, 05:59

Once you use the exe, is there a way to make it just search for GQ factors of GM factors. How do you produce an input file for LLR from the output of the program.

Batalov · 2014-04-09, 07:16

Not at this time. You simply get all factors in the requested bitrange. It is running the program that is computationally expensive (and the runtime is the same* regardless if you are searching for one kind, for another or for both), while filtering is extremely easy and instantaneous. All filters can be easily done with grep. If there's a "(2^", then it is a GQ factor, if not, then it's a GM factor.

The benefit is that you can later run "Factor=gm,#######,60,61" and combine the output data in any fashion you want.

One option that could be good to add is to stop when factors on both sides are found, but my next free time window is not soon. Any volunteers to add this? The source is open.

______
*and the same is true for llr

Cruelty · 2014-05-15, 08:37

I have finally finished my range till 2M. Citrix + Batalov - what is your status?

Batalov · 2014-05-16, 03:08

I am at 5.0M for GMs and at 4.7M for "GQ-only"s.

Batalov · 2014-09-03, 17:45

Quote:

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.

I'd like to verify that GM(4792057) is the Gaussian Mersenne norm #39.
I can double-check everything up to 3.5M+delta, and check up to 3.85M, if this range is now abandoned. If it is not abandoned, please let us know.
__________________________

Also, on another topic: I'd like to share with you my recent realization that Gaussian Mersenne norms are Generalized unique primes, too.

For example GM(4792057) = Phi(4, 2^2396029-1)/2.
Recall that Phi(4, x) = x^2+1 and Generalized unique primes are Phi(n,x)/gcd(n,Phi(n,x)); gcd(4,Phi(4, odd x)) is 2. For EM norms, similarly gcd()=3.
Mike Oakes would probably say that this is a trivial observation, and it definitely is.

Citrix · 2014-09-04, 03:47

Quote:

Originally Posted by Batalov

I'd like to verify that GM(4792057) is the Gaussian Mersenne norm #39.
I can double-check everything up to 3.5M+delta, and check up to 3.85M, if this range is now abandoned. If it is not abandoned, please let us know.
__________________________

As I mentioned above, I sieved the range up to 60 bits, but once I realized that LLR was missing factors I had stopped there. I tried to get the GPU sieve to work, but could not get it to run on my computer.

I can provide you the pre-sieved file and list of the 10-20% of candidates that I tested before, but if LLR is missing factors, it might be best to start this range from scratch.

Batalov · 2014-09-04, 21:54

I am not trying to dissuade you to run this range (nor my initial message about missed factors was aimed at that).

I see a common thread here with something that I hear sometimes at the PrimeGrid forums: "we need to get the pre-factoring (a.k.a sieving) done precisely right. If we have problems with sieving, we cannot proceed. The whole hell will break loose. That's why we sieve with replication factor 2."
But that is not true. (It is even worse to do that sieivng in duplicate, but LLR with adaptive replication. Oh, the horror. Oh, the misplaced priorities.)

Let's consider the pipeline of testing. You have a finite set of candidates. You remove some by pre-factoring. Then you N-1-test. What happens if 1-2... or even 20 out of a few thousand factors are lost? Nothing too bad. You will run an unnecessary N-1 test and you will not miss a prime.

The only danger you can have is when a factor is reported when there is none. When the factor is invalid. But this is easy (instantaneous!) to check with Pari/GP! This can be done before N-1-testing, at the same time, or even after! If an invalid factor is found, throw the candidate back into N-1 testing pool again, and you are done. What is important is keep all work (all factors and all residues) and in the end tally up against the input set, and (optionally) retest some N-1 tests and all factors (because this last part is insanely cheap).

Is it good to have all factors removed? -- yes, you bet.
Is it important to have all factors removed? -- no! A miniscule loss is acceptable, because it is righted at the next step.
Is it right to throw you hands in the air and say "nothing works, so I will just sit and wait while someone repairs everything"? -- I don't think so.
There are multiple ways to proceed even with imperfect tools.

Come to think of it, no tools are perfect. One cannot wait for the tools to become perfect and them proceed, because this moment will never come.

That's just my 2 cents. You don't have a roadblock and you never had. You may have thought that you had but you didn't. With that, would you like to proceed? or proceed to a smaller range?

2014-04-08, 06:18	#133
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2²×23×103 Posts	Your binaries work fine, Jerry. Thanks from all of us! In the meantime, I've got a full Studio 2012, uninstalled all 2013 mscrap, installed 2012, uninstalled CUDA5.5 (it was configured on the fly to not work, because "you have an unsupported version of the studio; only 2008, 2010, 2012 are supported", and that crap doesn't go away even after 2012 is installed), installed 6.0. Testcase: 1. (I forgot to edit that into mfaktc.ini) change "SievePrimesMin=2000". This is because we are in a very low range in GMQs, still, compared to M. 2. Selftests (8 of them) pass; that's already good. 3. Use "Factor=gm,4748941,1,60" in worktodo.txt 4. Get this in results.txt: Code: (2^4748941-2^2374471+1)/5 has a factor : 1326550183177 [TF:1:60:mfaktc 0.20 75bit_mul32] 2^4748941+2^2374471+1 has a factor : 1401773408617 [TF:1:60:mfaktc 0.20 75bit_mul32] found 2 factors for GM(Q)4748941 from 2^ 1 to 2^60 [mfaktc 0.20 75bit_mul32]

2014-04-09, 00:41	#135
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2²×23×103 Posts	They might be good for the people who would rather run it as they would mfaktc (with just libcudart64_55_....dll in the same directory; I don't know how volatile the libcudart64_60 will be). I probably will continue to run my linux binaries. I have now restored my dev environment at home, too. (I've ~~lost~~ never reinstalled it after I'd moved from a well lived-in XP to Win7, and oh well I didn't have much to build recently; the mmff-gfn branch grew stable... Maybe I'll grow an extra limb to the mmff - and expand into higher n values for Fermat factoring, now. Unsure if I have time.) P.S. I wrote the thing because I anticipated another long stretch to go for both G-M and E-M, but they both succumbed! I, frankly, will wrap my search after I will finish the range that I reserved. Warning: the new FFT size is imminent at or after 5.1M, too. The tests will be quite like watching the paint dry. Maybe a should start a new ~~sect~~ BOINC project. ;-) Last fiddled with by Batalov on 2014-04-09 at 00:47

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
New PC dedicated to Mersenne Prime Search	Taiy	Hardware	12	2018-01-02 15:54
Gaussian integers- use of norms	devarajkandadai	Number Theory Discussion Group	11	2017-10-28 20:58
Low clock speeds on Mersenne Prime search	Ammonia	Hardware	2	2016-01-21 17:46
Testing Mersenne cofactors for primality?	CRGreathouse	Computer Science & Computational Number Theory	18	2013-06-08 19:12
Can I specify the range to search the Mersenne Prime?	Unregistered	Information & Answers	22	2012-03-20 11:38

2014-04-08, 23:46	#134
flashjh "Jerry" Nov 2011 Vancouver, WA 1,123 Posts	You're welcome. Do you still want CUDA 5.5 binaries?

2014-04-09, 05:59	#137
Citrix Jun 2003 2×7×113 Posts	Once you use the exe, is there a way to make it just search for GQ factors of GM factors. How do you produce an input file for LLR from the output of the program.

2014-04-09, 07:16	#138
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2²×23×103 Posts	Not at this time. You simply get all factors in the requested bitrange. It is running the program that is computationally expensive (and the runtime is the same* regardless if you are searching for one kind, for another or for both), while filtering is extremely easy and instantaneous. All filters can be easily done with grep. If there's a "(2^", then it is a GQ factor, if not, then it's a GM factor. The benefit is that you can later run "Factor=gm,#######,60,61" and combine the output data in any fashion you want. One option that could be good to add is to stop when factors on both sides are found, but my next free time window is not soon. Any volunteers to add this? The source is open. ______ *and the same is true for llr

2014-05-15, 08:37	#139
Cruelty May 2005 2³×7×29 Posts	I have finally finished my range till 2M. Citrix + Batalov - what is your status?

2014-05-16, 03:08	#140
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2²·23·103 Posts	I am at 5.0M for GMs and at 4.7M for "GQ-only"s.

2014-09-04, 21:54	#143
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2²×23×103 Posts	I am not trying to dissuade you to run this range (nor my initial message about missed factors was aimed at that). I see a common thread here with something that I hear sometimes at the PrimeGrid forums: "we need to get the pre-factoring (a.k.a sieving) done precisely right. If we have problems with sieving, we cannot proceed. The whole hell will break loose. That's why we sieve with replication factor 2." But that is not true. (It is even worse to do that sieivng in duplicate, but LLR with adaptive replication. Oh, the horror. Oh, the misplaced priorities.) Let's consider the pipeline of testing. You have a finite set of candidates. You remove some by pre-factoring. Then you N-1-test. What happens if 1-2... or even 20 out of a few thousand factors are lost? Nothing too bad. You will run an unnecessary N-1 test and you will not miss a prime. The only danger you can have is when a factor is reported when there is none. When the factor is invalid. But this is easy (instantaneous!) to check with Pari/GP! This can be done before N-1-testing, at the same time, or even after! If an invalid factor is found, throw the candidate back into N-1 testing pool again, and you are done. What is important is keep all work (all factors and all residues) and in the end tally up against the input set, and (optionally) retest some N-1 tests and all factors (because this last part is insanely cheap). Is it good to have all factors removed? -- yes, you bet. Is it important to have all factors removed? -- no! A miniscule loss is acceptable, because it is righted at the next step. Is it right to throw you hands in the air and say "nothing works, so I will just sit and wait while someone repairs everything"? -- I don't think so. There are multiple ways to proceed even with imperfect tools. Come to think of it, no tools are perfect. One cannot wait for the tools to become perfect and them proceed, because this moment will never come. That's just my 2 cents. You don't have a roadblock and you never had. You may have thought that you had but you didn't. With that, would you like to proceed? or proceed to a smaller range?