20150417, 19:35  #45  
P90 years forever!
Aug 2002
Yeehaw, FL
1D92_{16} Posts 
Quote:
The lost data is in the factoring effort table that stores the TF bit depth and P1 bounds. This rows in this table are small so DB size was not an issue. The problem is that the way the database originally designed (way back in 1996) an exponent is expected to be in one and only one of the following tables: knownfactors, factoringeffort, knownMersenneprimes. There is fair amount of PHP and stored procedures that count on this. If the factoringeffort row is not deleted when a factor is found, then the makeexponentavailableforassignment stored procedure will break. If an exponent is in the factoringeffort table then the exponent is made available for TF,P1,LL,or DC. If the exponent is in the factors table then the exponent may be made available for ECM assignments. Can this be "fixed"? Yes, but it not a riskless proposition. 

20150417, 20:59  #46  
"James Heinrich"
May 2004
exNorthern Ontario
3^{2}·5·7·11 Posts 
Quote:
Quote:
Quote:
As suggested in some thread several months ago, just move the data into another archive table before deleting the row should be a relatively consequenceless modification. How far back does log data go, and how much could be reparsed to reconstruct all the data that's been tossed over the years, for TF levels and P1 runs? 

20150417, 21:46  #47  
P90 years forever!
Aug 2002
Yeehaw, FL
2×5×757 Posts 
Quote:
I have log files going back to at least 2000. If you combined these logs with the results log table on the server you should be able to reconstruct much of the data. If you are interested, I can zip these old logfiles up and email them to you. Alternatively, there may be a way to upload them to the server and add them to the results log table  probably the best option. 

20150417, 22:15  #48 
"James Heinrich"
May 2004
exNorthern Ontario
6611_{8} Posts 
I would expect the log files would be bigger than feasible to email, but I'm sure you can get them to me somehow. Merging them into the existing server database would be nice, but I'd still like an offline copy to fiddle around with. Please send them to me.

20150426, 08:18  #49 
Dec 2002
818_{10} Posts 
There are 21,000+ exponents listed now. Can you say anything about how this list was compiled and how new finds are added to it?
(and it would be handy if we could have a 'from ... to ...' selection mechanism.) 
20150426, 13:30  #50  
"James Heinrich"
May 2004
exNorthern Ontario
D89_{16} Posts 
Quote:
The variability of number of exponents on this list is due to poor quality of historical data as mentioned several posts back.I have parsed George's logs and sent them back, hopefully they'll be integrated into PrimeNet data over the next week or few so that real historical data will be available for factored exponents. Quote:
I happened across a "missing factor" exponent that I had P1 tested myself. I looked up the result file from 4 years ago and indeed it had failed to find the factor for M58,020,869: Code:
[Sat Feb 05 23:11:33 2011] UID: JamesHeinrich/Q6600, M58020869 completed P1, B1=685000, B2=18152500, We4: DC08ABF9, AID: 00E18F6BDCDCCAD486C7A875A153FB3B 

20150426, 20:10  #51  
"James Heinrich"
May 2004
exNorthern Ontario
3465_{10} Posts 
Quote:
Part of the increase can also be blamed on me finding new data on a number of P1 runs that have been done on small exponents, and I suspect in many of the cases the tiny factors were already known but P1 was run anyways to look for other factors. I think this would be one random example of that. Unfortunately I don't have any way of differentiating a P1 run that explicitly ignored known small factors vs one that simply failed to find a factor (like mine above). 

20150427, 11:00  #52 
"Victor de Hollander"
Aug 2011
the Netherlands
2^{3}×3×7^{2} Posts 
Looking at the BrentSuyama list:
http://www.mersenne.ca/brentsuyama.php it has a lot of exponent listed with factors found with normal P1, ECM and even a few found by TF. I don't know if this has always been the case, or if it was a sideeffect of importing the missing P1 results? For instance found by TF: M69,599,389 M69,277,711 M69,255,149 M69,243,721 M69,160,681 Found by ECM/normal P1: M1,595,057 M1,595,149 M1,595,983 M1,596,667 M1,597,763 M1,400,261 M1,152,517 M1,150,927 M870,047 M1,597 I only really thrust the ~250 of the 1000 that have the BrentSuyama exponent listed, the rest is probably just noise. 
20150427, 12:05  #53 
Romulan Interpreter
Jun 2011
Thailand
2×3×5^{3}×13 Posts 
Indeed, some of those are TF factors, since the old times when reporting a "factor" line without a "no factor" line in front, caused the GPUTF factors to be recorded as P1 factors (PrimeNet didn't know about TFing "so high" as 74 bits). That issue is fixed now, but the 74 bits TF factors remained stored as P1 factors.
Last fiddled with by LaurV on 20150427 at 12:06 Reason: s/64/74/ 
20150427, 14:55  #54 
"James Heinrich"
May 2004
exNorthern Ontario
3465_{10} Posts 
As LaurV said, the old manual results form assumed any large factor was found by P1 (and any really large factor on small exponents was found by ECM) while ignoring any clues as to how it was actually found. Using your first example of M69599389, the actual submitted result line was
Code:
M69599389 has a factor: 12698076768763159146287 [TF:73:74:mfaktc 0.20 barrett76_mul32_gs] Last fiddled with by James Heinrich on 20150427 at 14:55 
20150427, 16:11  #55  
Serpentine Vermin Jar
Jul 2014
3,313 Posts 
Quote:
As long as the raw message contains something clearly indicating the method (like the TF in your example) that should be possible. It may be slow to query since doing partial matching in SQL is generally slow, but if I can whittle down the list of results to check it may not be too bad. Something along the lines of: where result_type=pm1 factor and message like '%TF%' If these results only came from manual clients and they all start with "Mxxx has a factor" then the LIKE clause could be LIKE 'M%TF%' which is actually a lot faster. 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
F12 factor found?  johnadam74  FermatSearch  16  20161103 12:10 
Mfaktc keeps going after a factor is found  NBtarheel_33  GPU Computing  11  20120407 21:12 
found this factor  tha  Factoring  4  20070618 19:56 
After a factor is found it keeps on going  jocelynl  Software  6  20040807 01:31 
Odd Reporting of a Factor Found  Reboot It  Data  3  20031203 14:39 