Prime95 version 29.4

[Gordon]

Originally Posted by Prime95

Seems pretty obvious to me it is the person that did the PRP.

Really? The person who *proved* it prime is the one who ran the LL test isn't it?

[James Heinrich]

Originally Posted by Gordon

Really? The person who *proved* it prime is the one who ran the LL test isn't it?

Or is it the second person who ran the LL test, proving that the first LL test was accurate?


My opinion is the first person to make some reasonable claim, by whatever method, that a specific Mersenne number is prime, which is later proved to be true, should be credited as the discoverer.

[Prime95]

Originally Posted by James Heinrich

My opinion is the first person to make some reasonable claim, by whatever method, that a specific Mersenne number is prime, which is later proved to be true, should be credited as the discoverer.

The key word is "discoverer" not "prover".

[retina]

Originally Posted by Gordon

This! - let's not get carried by doing *probable* testing, the goal of the project is to find Mersenne Primes, the only way to guarantee that is to do the full LL test, followed by a verification run.

You can argue all you like but no matter how much you say ah yes, well, PRP is 99.9999% (or whatever number you care to plug in) it's a prime, you don't KNOW that for a fact....the chance if it being wrong are not zero.

I think everyone already knows that.

[preda]

Originally Posted by Gordon

This! - let's not get carried by doing *probable* testing, the goal of the project is to find Mersenne Primes, the only way to guarantee that is to do the full LL test, followed by a verification run.

You can argue all you like but no matter how much you say ah yes, well, PRP is 99.9999% (or whatever number you care to plug in) it's a prime, you don't KNOW that for a fact....the chance if it being wrong are not zero.

Well, comparing an LL proved-prime result with 96% reliability, and a PRP probable-prime result with 99.99% probability and 99.99% reliability, I'd take the PRP.

[Prime95]

Originally Posted by S485122

It seems that some lines are output to the worker window a second time with a different time stamp.
At the same time there is a communication with the server, only the expected completion date of the current workunit is sent to the server (according to prime.log) and the number of completed iterations of the previous worker screen output is written to result.txt. This happens every 160 minutes and 210000 iterations approximatively.
I checked : the program is not repeating the iterations, meaning the iteration count of the lines on the screen and results.txt is wrong.
This behaviour is observed with prime95 and mprime 29.4.3.

Could you provide more details? Work type? Screen shot?

Note to all: 29.4 sends interim residues to the server for the 500,000th iteration and every multiple of 5,000,000. This was Madpoo's idea to give us the ability to do a quick(ish) partial check should be want to.

[ATH]

Originally Posted by James Heinrich

Or is it the second person who ran the LL test, proving that the first LL test was accurate?


My opinion is the first person to make some reasonable claim, by whatever method, that a specific Mersenne number is prime, which is later proved to be true, should be credited as the discoverer.

If a PRP test says probably prime it might be more likely to be prime than a positive LL test, due to the fact that with Gerbicz error check the risk of hardware error is lower, and the extra risk of it being a 3-sprps is infinitesimal at these sizes.

[S485122]

Originally Posted by Prime95

Could you provide more details? Work type? Screen shot?

Note to all: 29.4 sends interim residues to the server for the 500,000th iteration and every multiple of 5,000,000. This was Madpoo's idea to give us the ability to do a quick(ish) partial check should be want to.

OK it makes sense then. But it means there is a bug in the screen and results.txt file output : instead of the real number of iterations it is the last number of iterations output to the screen that is shown. Also I see no trace of output for the 500 000th iteration.

Another new feature that was not documented in what's new is that at the start of a LL test there is now a line "Starting primality test of Mxxx using FMA3 FFT length 2304K, Pass1=384, Pass2=6K, clm=2, 6 threads".

Attached, screen output, excerpt of results.txt and prime.log. I marked the "new" lines are marked "+ ".

Anyway that output belongs in the Communication window and prime.log only. It should be something like "sending interim residue for iteration 9000000 of M99999999 to server"...

I will end with two wishes :
- The possibility to have the time stamps output to the screen, the prime.log and results.txt files in ISO format. It could be a setting in one the configuration files.
- The other one is to have each result in results.txt preceded by a time stamp : at the moment there is no time stamp if two results come within a few minutes of each other (very short assignments or multiple workers.)

Jacob

[Prime95]

Originally Posted by S485122

OK it makes sense then. But it means there is a bug in the screen and results.txt file output : instead of the real number of iterations it is the last number of iterations output to the screen that is shown. Also I see no trace of output for the 500 000th iteration.

Ah, I see the bug now. Don't know why I missed seeing it here. There's not supposed to be any screen output or results.txt output when sending an interim residue to the server. A "left over" line from a cut/paste operation is reprinting the last line output.

I've improved the text message output to prime.log.

[Madpoo]

Originally Posted by GP2

It might be useful to post SHA256 sums.
...

p95v294b3.FreeBSD11-64.tar.gz - 0F3A089E7AAB1A38F6FCF241A80D2B3D2EF95A3B758B87C6718012972207AB31
p95v294b3.linux32.tar.gz - CE944D628FB1CB0FA165BF7423957981F575A20961AE9C96D4691BCC4B0DE549
p95v294b3.linux64.tar.gz - EFC2B3EDB47B5625BE446101F14B832DD0D13FCD3B51B738D1AAC24C36585108
p95v294b3.MacOSX.zip - 180F7EAC59316ED298D4BCB479F4952B27059F2BD7D7011118A5A26A17E24FDC
p95v294b3.source.zip - C7B21388342A43AA4E50F9B2394DE0A422A56DB6BEACD0E17B05944854321664
p95v294b3.win32.zip - 5436C674230A040EE68B420872061AEE65E136BBC2460B3C285D4B0885D514AD
p95v294b3.win64.zip - AD0576CA2E63BB433A2A2D0974EF3D481ACAEA300E7C52466D5DE882D7C82B17

[Madpoo]

Originally Posted by Prime95

Could you provide more details? Work type? Screen shot?

Note to all: 29.4 sends interim residues to the server for the 500,000th iteration and every multiple of 5,000,000. This was Madpoo's idea to give us the ability to do a quick(ish) partial check should be want to.

Oh cool... that will be helpful. I've been off the forum for the past week so I guess I missed this news.