![]() |
1 Attachment(s)
Here is the list of pairs
I will redo them and send you the results so you have the correct residues. |
Tops. Saved to my desktop.
|
Okay, I've deleted the two problem primes from the PRPnet server's database and re-inserted the respective candidates. They were promptly reassigned to two of Lennart's clients and should be returned within 10 minutes or so (composite, of course). I adjusted PRPnet's stats tallies appropriately as well. [I](Note: I adjusted the "primes found" counts for both PCZ and Free-DC but not the "tests performed" counts, since that would also involve messing with the points count and that would be a mess. Since he'll be re-testing the same candidates manually on a stable machine, the stats will still be accurate in the end.)[/I]
As for the rest of the candidates tested by PCZ's unstable machine, those would be a bit more tricky to delete; I deleted the two primes from the PRPnet database individually, i.e. by typing in each candidate name specifically. This, of course, would be impractical for a long list of candidates; and it isn't really necessary anyway since we're re-doing them manually, not through the PRPnet server. Since the re-dos for the bad results will be done by the same user as before, fixing them in the main stats database should be fairly easy--once he completes the tests, we run a diff to compare the old and new results, and whichever residuals are different we fix with: [I]update results set residual=[new] where k=[k] and n=[n];[/I] respectively for each corrected residual--a MySQL script file with commands in the above format should be easy enough to whip up by a Perl script or the like. The end result will be that nothing changes except the residuals are now correct. The only thing this doesn't take into account is the raw text results files from which the DB initially loaded the results--those will still have the incorrect residuals in them. This isn't too big a deal since they'll already be fixed in the DB, but if we did ever have to reload the entire DB from the results files (say, if it was somehow lost), we'd end up with the incorrect residuals. Dave, how do you think we should handle this? |
Might be worth seeing if other results from the machine are affected before giving it too much thought. It is incredibly unlikely that two composite numbers would be found to be prime just from random residues.
|
[QUOTE=henryzz;290343]Might be worth seeing if other results from the machine are affected before giving it too much thought. It is incredibly unlikely that two composite numbers would be found to be prime just from random residues.[/QUOTE]
Yes, but I'm not sure if random residues are the sole factor in creating false-positive results; while I will admit I don't have any mathematical basis for such a claim, empirically, there are a lot of false primes that have been turned up over time, far more than would be expected if it was just a random 0 residue. (There's a thread at CRUS from a while back where we calculated how many tests it would take to crank out a random composite residue containing a 9-hexdigit string, and it was quite huge.) False primes seem to be a (somewhat) common type of bad result produced by unstable machines, so I'm thinking there must be something more to it that can "bias" the incorrect result toward positive in certain types of instability situations. |
[QUOTE=mdettweiler;290302]Dave, how do you think we should handle this?[/QUOTE]
I can pull them from the files, no problems, but I think we should see what results PCZ comes back with from the other machine before I make permanent changes to the results files. |
I think the NPLB server should automatically verify the primes found. If it is confirmed as prime then nothing happens, if it is confirmed as composite then the pair should go into the server to be tested again.
|
[QUOTE=AMDave;290436]I can pull them from the files, no problems, but I think we should see what results PCZ comes back with from the other machine before I make permanent changes to the results files.[/QUOTE]
Wait for my results to come back. Could be that there were only the two false positives and the rest of the tests were OK. Haven't finished quite yet, but so far it doesn't look too bad. Another 12 hrs or so and they will be finished and the residues can be compared. |
Added [URL="http://primes.utm.edu/primes/page.php?id=104945"]104945[/URL] : 741*2^1027639-1 (309354 digits) is prime.
-- Lumiukko |
Added [URL="http://primes.utm.edu/primes/page.php?id=104956"]104956[/URL] : 727*2^1031225-1 (310433 digits)isPrime
Lennart |
Added [URL="http://primes.utm.edu/primes/page.php?id=104966"]104966[/URL] : 703*2^1031219-1 (310431 digits) is prime.
Odi |
| All times are UTC. The time now is 22:57. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.