Cleared exponents that never made it into data files
We extract all unique exponents from cleared.txt (cleared exponents), dated 14 Sep 2003 20:00 UTC.
Then we extract all unique exponents from BAD, LUCAS_V.TXT, HRF3.TXT, and factors (all exponents that have ever had an LLtest returned or a factor returned), from the Sept 9 2003 data files (updated roughly weekly). Then we look for unique exponents that are found in cleared.txt but not in any of those data files. There are 1522 exponents. However, we eliminate any cleared result with a return date after 09Sep03 (results returned more recently than the last edition of the data files). When we do that, however, we still get 15 results: [code] 14572163 66 0x96FCC960D47A09__ 19Nov02 00:14 S78380 CD2AD6EAD 15370879 103 F 7757301118393895425291596492654 19Sep02 15:40 S09625 C2EE070A4 15729167 102 F 4489874295809814634906444128101 20Sep02 12:17 S09625 C2EE070A4 15953537 66 0xAB132582134FD2__ 09Jan03 10:47 S81293 C0B531E29 16878139 65 0x80C974D551468F__ 14Mar03 07:03 eteo teerex 18050569 67 0xF5C8DA9CAFCE13__ 25Mar03 13:40 timesau 1_gigr 18167557 67 0xB016E51AB1002C__ 24Mar03 21:55 typhoonmike Biohazard 18583559 67 0x7A1E8002C69347__ 24Jul03 06:00 S38041 C85D4A152 18734293 67 0xE3F3F278A93C42__ 29Aug03 06:53 dramacutie303 Katherine_B 18956551 67 0x53FF8EF6D6CAAF__ 18Aug03 12:31 mkroska webwslfh 19634569 66 0x21:__ 17Jun03 13:15 RichJacot yoda 19857121 67 0x12EE5DB062B25C__ 20Jun03 03:12 transcend pope 21558739 61 F 2782804445561117561 07May03 06:16 S103771 CC0AD6257 23180177 58 F 224966031444110303 30Jul03 14:44 ricsodre PlasmaWall 33238477 69 0xD12F51397BCA23__ 01Sep03 14:16 S67532 C7364A0E9 [/code] The residue for 19634569 is garbage, naturally. Checking the factors by verifying whether (2^p  1) mod f == 0, using an extendedprecision math package, it turns out that first two huge ones (103 and 102 digits) are bogus, but the final two smaller ones are perfectly valid, yet are not in the factors database! By the way, one of those 15 exponents just happens to be 33238477, mentioned in the [url=http://www.mersenneforum.org/showthread.php?s=&threadid=1110]missing?[/url] thread, with a return date of 01Sep03, which prompted this latest investigation. A rather amazing coincidence. George? 
Re: Cleared exponents that never made it into data files
[QUOTE][i]Originally posted by GP2 [/i]
Checking the factors by verifying whether (2^p  1) mod f == 0, using an extendedprecision math package, it turns out that first two huge ones (103 and 102 digits) are bogus, but the final two smaller ones are perfectly valid, yet are not in the factors database! [/QUOTE] Very large factors are truncated in the Primenet reports which is why the 102 and 103 bit factors appear bogus. The actual factors found are actually larger than 102 and 103 bits, and the correct factors do get to George, even if they don't show up on Primenet correctly. Also, the server will reject any factors that don't pass a simple verification calculation. That's how we know that no bad factors have ever caused us to miss a prime. 
Prime95 sends two messages to the primenet server when an exponent completes. The text based one I use to maintain my databases, the other one is used by the server to update its databases and print the cleared exponents report. In eleven of these cases, the server got its message, but I never got the text based one.
I've added the nine LL tests and the two missed factors to my database. Thanks data guru! 
Re: Re: Cleared exponents that never made it into data files
[QUOTE][i]Originally posted by NickGlover [/i]
[B]Very large factors are truncated in the Primenet reports which is why the 102 and 103 bit factors appear bogus. The actual factors found are actually larger than 102 and 103 bits, and the correct factors do get to George, even if they don't show up on Primenet correctly. [/B] [/QUOTE] Hmmmm, you're quite right. cleared.txt has the following: [code] 16091291 103 F 7362770625422642419324076409959 05Dec02 04:11 S24590 4 18965599 103 F 8602653675602192712514732427431 30Apr03 04:46 S58485 CHERRY 33475447 103 F 7621901790064563660031276374525 14Aug03 17:44 eipi ulka [/code] Whereas the actual factors are 16091291,117362770625422642419324076409959 18965599,34488602653675602192712514732427431 33475447,7621901790064563660031276374525079 (1st = 2 digits truncated at the start) (2nd = 4 digits truncated at the start) (3nd = 3 digits truncated at the end) Now, if we were missing the above actual factors, we could still reconstruct them based on the cleared.txt values. This can be done by running a script that adds every combination of up to 6 digits at the start or the end of the truncated factor, and then checking each new value for (2^p  1) mod f == 0 using an extendedprecision arithmetic package like libgmp on Linux. This takes about a minute or so on a 2.8 GHz P4. However, I was unable to reconstruct the factors (if they actually exist) for the original exponents in question: 15370879 15729167 I tried every combination of up to extra 6 digits at the start or up to 6 at the end, without any luck. However, there's also some weird stuff in cleared.txt. Check this out: [code] 8276539 103 DF 7411192628700266363789140779170 18Nov02 00:48 Team_Prime_Rib Tasuke18 17699497 103 F 8254656556609760068242738155742 26Mar03 08:12 Team_Prime_Rib KL_MLChan 18129493 103 F 8754500160125057908417949485956 24Feb03 07:26 curtisc wde310009 [/code] What's wrong with this picture? 1) These are all bogus factors. 2) Even assuming they were truncated by up to 6 digits at the start or up to 6 digits at the end, they're still bogus. 3) Much smaller known factors exist: 8276539,67600209174876814543 17699497,73630130820677243353 18129493,303330458703290742127 There are a number of similar examples, I haven't yet investigated how many, with many different users. [color=red]I singled out a couple of Team_Prime_Rib exponents: maybe you guys can contact those folks and ask them what's in their results.txt.[/color] Maybe we can figure out why huge bogus factors are getting sent to the server... And I'm guessing that 15370879 15729167 are also bogus in the same way as the above (with the only difference being, for those two cases, we don't have any muchsmaller known factors, in fact no known factors at all). [QUOTE][B]Also, the server will reject any factors that don't pass a simple verification calculation. That's how we know that no bad factors have ever caused us to miss a prime. [/B][/QUOTE] Actually, we also can do the (2^p  1) mod f == 0 test on the entire factors database. With a 2.8 GHz P4, the entire database of 2,651,013 factors can be verified in a couple of minutes. I've done this, and there are indeed no bad factors. 
Note that sometimes when P1 finds a really large factor, the factor itself is not prime and may be the product of multiple factors. George will usually factor these large P1 factors and put only the smallest prime factor into his database.
So, you may find that the factor you find in George's factors.cmp is completely different from what is on Primenet. This doesn't really invalidate your attempts at finding the actual factor for the three factors you listed. My best guess is that trying 6 digits on either side is not enough. I think the largest P1 prime factor ever found is something greater than 50 digits (166 bits), so it is plausible that those three factors are some part of the digit sequence for a product of valid prime factors of the Mersenne numbers in question. 
GP2 
for the following numbers: [code] 8276539 103 DF 7411192628700266363789140779170 18Nov02 00:48 Team_Prime_Rib Tasuke18 17699497 103 F 8254656556609760068242738155742 26Mar03 08:12 Team_Prime_Rib KL_MLChan 18129493 103 F 8754500160125057908417949485956 24Feb03 07:26 curtisc wde310009 [/code] Since the bit length of these numbers is significantly above the upper limit for trial factoring, these must have been found by the P1 factoring step. P1 factoring can find composite factors of M numbers, and when this happens, the server factors the reported factor and saves only the smallest prime factor of the reported number, i.e. the smallest known prime factor of the M number. This is probably what happened here. On a side note, the reported factors are 66, 66, and 69 bits, respectively. This means the server has an upper limit on the number of bits it reports. 
The factors for 15370879 and 15729167 do not exist. I did get the text message for those and the factors were bogus.

[QUOTE]My best guess is that trying 6 digits on either side is not enough. I think the largest P1 prime factor ever found is something greater than 50 digits (166 bits), so it is plausible that those three factors are some part of the digit sequence for a product of valid prime factors of the Mersenne numbers in question.[/QUOTE]
The largest factor found with P1 has 47 digits. The largest GIMPS factor found with P1 has 45 digits. [URL=http://www.loria.fr/~zimmerma/records/Pminus1.html]http://www.loria.fr/~zimmerma/records/Pminus1.html[/URL] the server only displays factors upto about 31 or 32 digits corectely. So i guess you'll have to add 1 or 2 extra digits in your test. 
Well, if a factor could be 45 digits and the report is only showing 31 or 32, I would think GP2 would need to try up to 14 digits in either direction. Also, if the factor is a product of prime factors, then GP2 may need to try even more than 14 digits to find the factor.

The link above shows the 10 largest factors ever found with P1 (if the file is up to date). Only 3 of these were found with prime95/mprime.
Factors found with p1 above 39 digits are rare (although i'm convinced many more will be found if more time is spend running P1 compared to ECM). If it takes 1 minute to test for 6 missing digits it will take about 190 years to test for 14 missing digits. I't might be faster to rerun P1 with high memory limits to see if the factor can be found again. 
I can run those P1s if someone tells me what the worktodo.ini line should be...
(I can't use Pfactor because I don't know what bit depth they were trial factored to, and I can't use Pminus1 because I don't know what bounds were used!) 
All times are UTC. The time now is 17:35. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2020, Jelsoft Enterprises Ltd.