20190224, 16:51  #45  
1110010110001_{2} Posts 
Quote:
There is nothing wrong, it is only that I am now TF'ing at bitlevels where no factors are around. But the idea that all the energy spent will have a value of 0 is somewhat confusing. 

20190224, 17:19  #46  
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
2·3·569 Posts 
Quote:
Note, if R. Gerbicz' recent TF NF verification proposal is implemented in some reasonably effective way, the motivation for the nofactor, nocredit position is diminished, possibly to the point of becoming moot. Until all the major TF client software and TF submission software is upgraded to incorporate TF NF verification, the manual reporting provisions and spiders would need to continue to support noverification reports. So forumspammers would still have a way, and Madpoo's intervention would still be needed, during this transition period. Last fiddled with by kriesel on 20190224 at 17:19 

20190224, 17:26  #47  
Serpentine Vermin Jar
Jul 2014
3255_{10} Posts 
Quote:
I think all exponents have had TF done up to some bit level in the 60s and if you're doing something like TJAOI is doing (in part, redoing TF, and actually finding some that were missed) I still feel like you'd find some. Could be argued that redoing TF isn't the best use for most people though. Maybe I should check your actual factorfound rate so I can talk more intelligently about the specific rate you're finding any instead of guessing. EDIT: Okay, I just crunched the #'s... you're finding 1 factor out of every 69 attempts (give or take). Looks like you're factoring to 2^71 or more so that's pretty normal. Is the 1 in 69 rate concerning to you? I'm not sure but I think that's roughly average. Last fiddled with by Madpoo on 20190224 at 17:38 

20190224, 18:03  #48  
2^{4}×67 Posts 
Quote:
No absolutely. Only I was finding more factors when I requested assignments up to bitlevel 76, so maybe I will restart doing that way. 

20190224, 18:19  #49  
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
2·3·569 Posts 
Quote:


20190224, 18:26  #50  
Serpentine Vermin Jar
Jul 2014
6267_{8} Posts 
Quote:
I just got done looking into the stats of a user who submits a LOT of TF results and their rate of finding factors is currently 1 in 72. In raw numbers, that's 104,185 factors found out of a total 7,540,548 attempts. So... look at it in the sense that your rate of finding factors is actually *better* than someone who has turned in over 7.5 MM TF results. 

20190224, 22:50  #51  
∂^{2}ω=0
Sep 2002
República de California
10,889 Posts 
Hey, don't blame the girl for being a natural multitasker!
Quote:
R. Gerbicz wrote: "As pointed out we send q only if it is prime (or pseudoprime), and you have to test these q primes whatever is your sieve bound." Careful  Not 'pseudoprime' in the sense that e.g. a^(q1) == 1 (mod q), rather, "no factors up to some sieving bound", said bound tyoically being on the order of 20 bits. As Kriesel noted, testing a factor candidate q = 2.p.k+1 for pseudoprimality to even a single base is several times more costly than simply testing whether q divides M(p) since the former involves computing a modpow with exponent ~= q whereas the latter needs just a modpow with exponent p, which is currently ~1/3rd as many bits as a typical q. While the statisticaloutlier approaches are interesting, as others have suggested we already have a supersimple way to solve the present problem  only give credit for factors found. Verification of such is trivial, and the odds of someone crunching away for THzyears without finding any follow the same statistical probabilities as described for catching TF creditfraudsters under the current system. Look at it this way: folks doing LL tests have far, far lower odds of success than TFers (though greater glory should they win the lottery), but that doesn't keep people from contributing. So my vote is to simply change credit to factorsfoound only, with the multipliers fiddled so that the total credit handed out under the new setup remains roughly equal to currently. For folks who go through a long factor drought, there is the carrot of "when do you find one eventually, you'll get a nice boost". And if their hardware is functioning properly, they *will* tend to the statistical expectedsuccessrate over time. In fact, the server could still compute the probabilities for each user as they turn in results, and flag extreme outliers in the "fewer found than expected" direction  too many sigmas would be a pretty reliable indicator of bad hardware or bad TFcode build, methinks. Quote:
1. You can request up to X TF assignments at a time, but once you have a certain number of outstanding ones, you can't get more until you submit a sufficient number of (alleged) results to get the numberoutstanding below the serverset limit. The server updates your TFprobabilityversusexpected number with each submission; once the count is high enough, too many sigmas outside the expectedsuccessrate gets you flagged to the sysadmin for "have a closer look at this user". Sysadmin will contact user re. possible hardware/badbuild problem if appropriate  if waytoolow success rate is due to such innocent causes, I'm sure the user will appreciate the headsup. 2. Remember that TF is not our "last line of defense" prior to doing a fullbore primality test; all TF nofactorsfound M(p) get p1 factoring done prior to LL test. Each p1 factorfound whose bitness is such that priorTF should have turned up the factor raises a red flag w.r.to the user who did the TF for the bitrange which should have found the factor. So we have two pretty good ways of catching problemhardwareorsoftware and TFfraudster issues, both of which involve fairly simple  though by no means trivial  serverside enhancements. Last fiddled with by ewmayer on 20190224 at 23:31 

20190224, 23:14  #52  
"Robert Gerbicz"
Oct 2005
Hungary
1,327 Posts 
Quote:
(2^p mod q) mod 2^t = 1. Roughly we're expecting 24000 q values (in the main wavefront with traditional sieving bounds), half of them is composite, the other half is prime, and we send only those 12000 q primes. Yeah, you could use a true primality test, but when among 1500 primes you could see maybe 0.000001 base=5 composite pseudoprime, it isn't that exciting, and your code will be just longer and maybe slower. Last fiddled with by R. Gerbicz on 20190224 at 23:16 Reason: typos 

20190224, 23:50  #53  
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
3414_{10} Posts 
Quote:
Quote:
Quote:
Quote:
Quote:
Last fiddled with by kriesel on 20190225 at 00:06 

20190225, 10:42  #54  
2·2,521 Posts 
Quote:
Still we are wise enough to name our gpus with unique names so that they can be distinguished inside the server database. For example I use for gpu0 RX5800 and for gpu1 RX5801, this should help distinguishing which gpu returned which result. 

20190225, 13:59  #55  
If I May
"Chris Halsall"
Sep 2002
Barbados
2^{2}×3^{2}×5×7^{2} Posts 
Quote:
Quote:
I appreciate what Aaron is having to deal with here (some twit(s) trying to promote their porn site by spamming the Primenet server with bogus results), but I stand by my arguement that not giving credit for TF'ing effort which doesn't find a factor is illadvised. 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Results  ET_  Operazione Doppi Mersennes  604  20200326 15:17 
Where have all the TF results gone?...  lycorn  PrimeNet  22  20171002 02:40 
PGS Results  danaj  Prime Gap Searches  0  20170814 18:35 
CPU Results last 24 hrs  Unregistered  Information & Answers  3  20100726 00:49 
0x results...  Mike  PrimeNet  11  20040523 12:55 