Prime95 version 29.3 - Page 6

MrRepunit · 2017-10-01, 18:51

Is it planned to implement the improved error check (given by Robert Gerbicz) for at least a subtype of PRP tests? I think the test is easy to derive/implement for any generalized repunits of the form (b^p-1)/(b-1), at least I could derive it easily for base 10 repunits.

Prime95 · 2017-10-01, 21:14

Quote:

Originally Posted by MrRepunit

Is it planned to implement the improved error check (given by Robert Gerbicz) for at least a subtype of PRP tests? I think the test is easy to derive/implement for any generalized repunits of the form (b^p-1)/(b-1), at least I could derive it easily for base 10 repunits.

Yes, I plan to implement the Gerbicz PRP error check. Unfortunately, this error check only works efficiently for base 2.

GP2 · 2017-10-02, 00:11

Prime95 could be modified to ensure that workers don't run an automatic (gwnum) benchmark in the middle of stage 2 of a PRP or ECM or Fermat test.

If a very large amount of memory is being used, then the stage 2 init could take a long time, for instance up to a couple of hours. It doesn't make sense to stop the worker to do the benchmark, because each time it restarts from a savefile that was in stage 2, it has to do the stage 2 init over again.

Also, I'm not sure if Fermat tests need the autobenchmark and gwnum.txt thing at all, because they are a fixed set of known exponents, and probably aren't near any FFT size boundaries. So perhaps for workers running a Fermat test, the worker should never stop to do an automatic benchmark.

I think there is the AutoBench=0 setting in prime.txt (documented in undoc.txt), but it really should be built in to the program itself.

Prime95 · 2017-10-02, 04:06

Quote:

Originally Posted by GP2

Prime95 could be modified to ensure that workers don't run an automatic (gwnum) benchmark in the middle of stage 2 of a PRP or ECM or Fermat test.

If a very large amount of memory is being used, then the stage 2 init could take a long time, for instance up to a couple of hours. It doesn't make sense to stop the worker to do the benchmark, because each time it restarts from a savefile that was in stage 2, it has to do the stage 2 init over again.

Will do.

S485122 · 2017-10-02, 04:50

Quote:

Originally Posted by GP2

Prime95 could be modified to ensure that workers don't run an automatic (gwnum) benchmark in the middle of stage 2 of a PRP or ECM or Fermat test.

If a very large amount of memory is being used, then the stage 2 init could take a long time, for instance up to a couple of hours. It doesn't make sense to stop the worker to do the benchmark, because each time it restarts from a savefile that was in stage 2, it has to do the stage 2 init over again.
...

P-1 factoring also has a memory intensive stage 2 that will be impacted in the same way.

GP2 · 2017-10-02, 05:18

Quote:

Originally Posted by S485122

P-1 factoring also has a memory intensive stage 2 that will be impacted in the same way.

I meant to write P−1, not sure why it came out as "PRP"...

storm5510 · 2017-10-02, 07:26

How do I configure Prime95 to run PRP tests? The program settings always override the settings for the CPU on the server. Perhaps I need the work-preference type numerical values and chance them in prime.txt.

GP2 · 2017-10-02, 08:38

Quote:

Originally Posted by storm5510

How do I configure Prime95 to run PRP tests? The program settings always override the settings for the CPU on the server. Perhaps I need the work-preference type numerical values and chance them in prime.txt.

It might be best to wait for 29.4, unless you're prepared to do some manual manipulation, due to a bug which is currently present in 29.3, namely: when the total length of the factor string (all factors written together with commas between them) is 40 or greater, then the PRP results can't be automatically reported properly to the server, but have to be manually reported instead.

storm5510 · 2017-10-02, 14:46

Quote:

Originally Posted by GP2

It might be best to wait for 29.4, unless you're prepared to do some manual manipulation, due to a bug which is currently present in 29.3, namely: when the total length of the factor string (all factors written together with commas between them) is 40 or greater, then the PRP results can't be automatically reported properly to the server, but have to be manually reported instead.

Thanks! I will wait. George had written something about adding the additional work types in the next release after I had asked about them.

GP2 · 2017-10-05, 16:59

A relatively minor but longstanding issue:

The undoc.txt option ContinueECM=1 causes ECM to continue even after a factor is found for a particular exponent. For instance, you might want to complete a t=25 or t=30 level.

This causes worktodo.txt to be updated: the number of curves is adjusted, to subtract the number of curves already run from the original amount specified.

However, the factor string is not adjusted to add the newly-discovered factor, so it is possible to rediscover the same factor again during the remaining curves.

Also, sometimes ECM detects that "Cofactor is a probable prime" and writes this to results.txt, however it then continues to test the exponent (if ContinueECM=1 was specified) even though it makes no sense to do so anymore.

GP2 · 2017-10-06, 01:42

PRP savefiles and LL savefiles have the same naming scheme (at least for exponents under 10M and above 80M, I didn't verify PRP savefiles for exponents in between those thresholds).

The savefile filenames start with p, and for exponents below 10M or above 80M, the rest of the name is just the exponent, for instance p6701207 and p82155461 for exponents 6,701,207 and 82,155,461 respectively.

In between 10M and 80M there's an 8+3 format for compatibility with old-style FAT file systems, which incorporates a single capital letter among numbers (e.g., p5L96247.bu2 for the exponent 46596247). The exact details are not relevant here.

Although the internal contents distinguish a PRP savefile from an LL savefile, including the 4-byte magic number at the start of the binary file, the filenames are identical.

There might be some situations where the two different kinds of savefiles end up overwriting one another. If anyone ever decided to run an LL test and a PRP test of the same exponent on different workers in the same work directory, for instance.

To avoid this problem, maybe it would be better if newly written PRP savefiles used a different letter prefix, other than "p". Old PRP savefiles starting with "p" could still be recognized and read, for backward compatibility, but they could be renamed by v 29.4 when it encounters them.

2017-10-06, 01:42	#66
GP2 Sep 2003 5×11×47 Posts	PRP savefiles and LL savefiles have same filename scheme PRP savefiles and LL savefiles have the same naming scheme (at least for exponents under 10M and above 80M, I didn't verify PRP savefiles for exponents in between those thresholds). The savefile filenames start with p, and for exponents below 10M or above 80M, the rest of the name is just the exponent, for instance p6701207 and p82155461 for exponents 6,701,207 and 82,155,461 respectively. In between 10M and 80M there's an 8+3 format for compatibility with old-style FAT file systems, which incorporates a single capital letter among numbers (e.g., p5L96247.bu2 for the exponent 46596247). The exact details are not relevant here. Although the internal contents distinguish a PRP savefile from an LL savefile, including the 4-byte magic number at the start of the binary file, the filenames are identical. There might be some situations where the two different kinds of savefiles end up overwriting one another. If anyone ever decided to run an LL test and a PRP test of the same exponent on different workers in the same work directory, for instance. To avoid this problem, maybe it would be better if newly written PRP savefiles used a different letter prefix, other than "p". Old PRP savefiles starting with "p" could still be recognized and read, for backward compatibility, but they could be renamed by v 29.4 when it encounters them.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Prime95 version 27.3	Prime95	Software	148	2012-03-18 19:24
Prime95 version 26.3	Prime95	Software	76	2010-12-11 00:11
Prime95 version 25.5	Prime95	PrimeNet	369	2008-02-26 05:21
Prime95 version 25.4	Prime95	PrimeNet	143	2007-09-24 21:01
When the next prime95 version ?	pacionet	Software	74	2006-12-07 20:30

2017-10-01, 18:51	#56
MrRepunit Mar 2011 Germany 3×31 Posts	Is it planned to implement the improved error check (given by Robert Gerbicz) for at least a subtype of PRP tests? I think the test is easy to derive/implement for any generalized repunits of the form (b^p-1)/(b-1), at least I could derive it easily for base 10 repunits.

2017-10-02, 00:11	#58
GP2 Sep 2003 5×11×47 Posts	Prime95 could be modified to ensure that workers don't run an automatic (gwnum) benchmark in the middle of stage 2 of a PRP or ECM or Fermat test. If a very large amount of memory is being used, then the stage 2 init could take a long time, for instance up to a couple of hours. It doesn't make sense to stop the worker to do the benchmark, because each time it restarts from a savefile that was in stage 2, it has to do the stage 2 init over again. Also, I'm not sure if Fermat tests need the autobenchmark and gwnum.txt thing at all, because they are a fixed set of known exponents, and probably aren't near any FFT size boundaries. So perhaps for workers running a Fermat test, the worker should never stop to do an automatic benchmark. I think there is the AutoBench=0 setting in prime.txt (documented in undoc.txt), but it really should be built in to the program itself.

2017-10-02, 07:26	#62
storm5510 Random Account Aug 2009 2²×3×163 Posts	How do I configure Prime95 to run PRP tests? The program settings always override the settings for the CPU on the server. Perhaps I need the work-preference type numerical values and chance them in prime.txt.

2017-10-05, 16:59	#65
GP2 Sep 2003 5·11·47 Posts	A relatively minor but longstanding issue: The undoc.txt option ContinueECM=1 causes ECM to continue even after a factor is found for a particular exponent. For instance, you might want to complete a t=25 or t=30 level. This causes worktodo.txt to be updated: the number of curves is adjusted, to subtract the number of curves already run from the original amount specified. However, the factor string is not adjusted to add the newly-discovered factor, so it is possible to rediscover the same factor again during the remaining curves. Also, sometimes ECM detects that "Cofactor is a probable prime" and writes this to results.txt, however it then continues to test the exponent (if ContinueECM=1 was specified) even though it makes no sense to do so anymore.