Is there independent check for found factors?

[bloodIce]

Out of curiosity I wonder if there is an Prime95 independent check that a factor is actually dividing an exponent? I guess the server checks somehow that the factor is not a mistake.

[chalsall]

Originally Posted by bloodIce

Out of curiosity I wonder if there is an Prime95 independent check that a factor is actually dividing an exponent? I guess the server checks somehow that the factor is not a mistake.

The PrimeNet server does check that any factor reported is in fact a factor.

Factor found reports to the PrimeNet server are impossible to fake.

(There is a corollary to this, which I won't go into....)

[bloodIce]

Thanks for the answer. I was more curious if it is Prime95 independent, but probably the division is trivial once you know a factor. I am not saying anything about the program, I simply like independent verifications.

[Uncwilly]

The factors are stored in the database. They are publicly available. A person could write some code that fetches the exponent and factor, then checks them. My understanding is that the total time for a single PC to verify each factor for the entire database would be less than 2 months (wild guess).

[mdettweiler]

Originally Posted by bloodIce

Thanks for the answer. I was more curious if it is Prime95 independent, but probably the division is trivial once you know a factor. I am not saying anything about the program, I simply like independent verifications.

PrimeNet's check is Prime95 independent; since the division is trivial, it is probably just done as a little bit of server-side PHP or ASP code in the routines that handle client communication. There is also an additional check, performed with the msieve factoring program (of no relation to Prime95) to verify that the factor reported is PRP (probably prime); if it is composite, then msieve will split it into its constituent prime factors within a minute or two. (The cofactor of the entire Mersenne number is not checked for primality because it is extremely large and this would be very time-consuming, but that's fine since as long as the factor divides the Mersenne number, it is proven composite regardless of the cofactor's primality.)

[TheJudger]

Originally Posted by Uncwilly

The factors are stored in the database. They are publicly available. A person could write some code that fetches the exponent and factor, then checks them. My understanding is that the total time for a single PC to verify each factor for the entire database would be less than 2 months (wild guess).

Bottleneck might be fetching the database. The test itself is _VERY_ fast and simple:

o@Lysithea:~/mfaktc/defactor> time ./defactor.exe 13828261 1979553586274192263311048622055057969

The factor 1979553586274192263311048622055057969 divides 2^13828261 -1! K = 71576374870064726985954655544
The factor 1979553586274192263311048622055057969 is probably prime

real    0m0.001s
user    0m0.000s
sys     0m0.000s

The defactor.c is a straight forward implementation using GMP. I have received the source from Luigi (ET_) and modified it a little bit.

Oliver

[Uncwilly]

Originally Posted by TheJudger

Bottleneck might be fetching the database. The test itself is _VERY_ fast and simple:

I had put a sentence to that effect in my reply, but deleted it before posting (I figured a big pipe and good timing might make that not true).

[petrw1]

However, what won't be verified is NO FACTOR found results.

If due to an error the software mistakenly misses a factor, the only way to verify it would be to rerun the TF....which is NOT done today unless someone chooses to do so manually or via a different program.

This simply means the exponent will (unnecessarily) continue to be available to further TF / P1 / LL / DC.

That was a thread a couple years ago that discussed a known bug in the factoring code in an old version but it suggests that the suspect ranges were all rerun.

[cheesehead]

Originally Posted by petrw1

However, what won't be verified is NO FACTOR found results.

Yes, it's well known that, in general, proving a negative is difficult. :-)

That was a thread a couple years ago that discussed a known bug in the factoring code in an old version but it suggests that the suspect ranges were all rerun.

However, we continue to get occasional reports of factors found in P-1 that should have been found by earlier TF, so the missed-factors problem has not yet been eliminated.

See the neighboring thread "M2629093 has a factor: 63721413359381377" at http://mersenneforum.org/showthread.php?t=15318 for more discussion of the missed-factors issue. Note George's comment in post #22 and mine in post #24 about the relative merits of devoting resources to re-TFing past searches (i.e., perfectionism) versus going a bit level deeper (i.e., productivity).

Re-TFing all past searches would take the same amount of work as simply extending all previous TF by one more bit, but would be less productive. Re-TFing may find a few missed factors, but extending all past TF by one bit would find hundreds of factors. Neither would help GIMPS's throughput.

[petrw1]

Originally Posted by cheesehead

Yes, it's well known that, in general, proving a negative is difficult. :-)

In general yes...

http://www.youtube.com/watch?v=sh163...eature=related

http://www.youtube.com/watch?v=KiIP_KDQmXs

[lycorn]