Prime95 version 29.4

[preda]

Originally Posted by Dubslow

That's still substantially less than the PRP-gerbicz reliability though, correct?

That suggests that GIMPS should mostly eliminate LL, though I suppose the benefits are marginal.

I would say the benefits of PRP-first-time vs. LL-first-time are major, not marginal; because *every* LL result is double-checked, even if the LL error rate is only 4%.

if LL wavefront is at N, and let's say the LL-double-check is at N/2, that would imply that 25% of total LL compute is used for double checks.

The gain from PRP would be these 25% being replaced by some small percent only.

[retina]

Originally Posted by preda

I would say the benefits of PRP-first-time vs. LL-first-time are major, not marginal; because *every* LL result is double-checked, even if the LL error rate is only 4%.

if LL wavefront is at N, and let's say the LL-double-check is at N/2, that would imply that 25% of total LL compute is used for double checks.

The gain from PRP would be these 25% being replaced by some small percent only.

You will still need double checks for every exponent even with a test regime that has known 100% perfect results. Because not everyone is honest, you can't simply accept a result and trust it.

[preda]

Originally Posted by Dubslow

That's still substantially less than the PRP-gerbicz reliability though, correct?

That suggests that GIMPS should mostly eliminate LL, though I suppose the benefits are marginal.

Originally Posted by retina

You will still need double checks for every exponent even with a test regime that has known 100% perfect results. Because not everyone is honest, you can't simply accept a result and trust it.

Yes I agree and understand this necessity. That's why I mention "the few percents" still needed for some kind of double-check to be established.

But my point was that the potential gain is 25%, not 4% (minus the PRP double check policy).

In the worst case, I would see the PRP-double-check as being: complete double check up to N/4 (vs. N/2 for LL now), and that'd be 25% (1/4) being replaced by 6% (1/16) "check tax".

[retina]

Originally Posted by preda

In the worst case, I would see the PRP-double-check as being: complete double check up to N/4 (vs. N/2 for LL now) ...

I think we need double checks up to N/1 regardless of LL or PRP or any other test type.

[preda]

Originally Posted by retina

I think we need double checks up to N/1 regardless of LL or PRP or any other test type.

But there's a trade-off between using the compute for finding new primes vs. verifying the existing results. We could even say that the goal is to find a new mersenne prime as fast as possible, and then the double-check arises as a natural outcome of efficient search.

Now, if you plug in some error rate of the existing results in the above formula, that would produce the "optimally efficient" rate of double-check. LL and PRP having different error rates, they'd require different rates of double-check.

We could say that a secondary goal is being able to say "there's no mersenne prime up to this value", and this would also play into the double check rate.

Also, maybe people come up with ideas about how to do "smart" double-check for PRP, which would validate mostly against malicious user action, not for correct computation.

[GP2]

I think the answer is straightforward:

1. Double checking will continue to exist, even after all old LL tests have been verified.

2. There will be multiple statuses reflecting increasing degrees of certainty: never tested; unverified; unverified but reliable; verified; factored. Just like today, except with that one additional status.

2. The project administrators will continue to decide "what makes the most sense" and might adjust the default ratio of double checks to first time tests. It might go from one in ten to, say, one in a hundred.

3. The "one double check a year" default might be turned off by default instead.

4. Each individual user will have the option of specializing in double checks, but considerably fewer will choose to do so. "Strategic" double checking will probably go extinct.

5. The backlog of double checks will increase from the current ten years behind first-time tests to twenty years or more.

6. Moore's Law will ensure that at least some double checking will be done no matter what. For example, LL testing all exponents up to one million was a milestone twenty years ago when the project was first starting, but now a single user with sufficient resources can do this over the course of a weekend.

7. LL tests will still be needed to prove a Mersenne prime, since strictly speaking, PRP tests can only prove that a Mersenne number is composite.

8. We will receive a transmission from extraterrestrials with a complete list of the first hundred Mersenne primes. Primenet disbands because we only managed to discover sixty of them ourselves so far and there's no point continuing. There will be a scandal because we should have discovered sixty-one, and the Russians were responsible.

[retina]

Originally Posted by GP2

8. We will receive a transmission from extraterrestrials with a complete list of the first hundred Mersenne primes. Primenet disbands because we only managed to discover sixty of them ourselves so far and there's no point continuing.

But we will still need to verify the aliens reported results. So DC will go into overdrive.

[preda]

If a new mersenne prime is found by PRP followed by LL verification, who is credited with finding the prime? I think an official statement on that is needed.

[Prime95]

Originally Posted by preda

If a new mersenne prime is found by PRP followed by LL verification, who is credited with finding the prime? I think an official statement on that is needed.

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

[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.

Jacob

[Gordon]

Originally Posted by GP2

7. LL tests will still be needed to prove a Mersenne prime, since strictly speaking, PRP tests can only prove that a Mersenne number is composite.

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.