And now for some TF results...

Originally Posted by Madpoo

If you're doing TF and not finding any factors, there's something wrong there (or in the case of these fraudsters, they're just making it up as they go).

There is nothing wrong, it is only that I am now TF'ing at bit-levels where no factors are around. But the idea that all the energy spent will have a value of 0 is somewhat confusing.

[kriesel]

Originally Posted by chalsall

I would argue against this idea...

It is true that /most/ people who do TF'ing don't really care all that much about the credits. But, *some* do.

Further, the "No Factor between 2^X and 2^Y" information is almost as valuable as a found factor. Not only to keep track of where the next bit (no joke intended) of TF'ing work should be done, but also P-1'ing takes this information into consideration.

Lastly, since there would be no "reward" to the participant to submit the "No factor found" information, some _might_ simply not submit such results, thus making others redo the work with the resultant lower "success rate".

My 4 cents (BDS)....

Plus, some primality test clients (including prime95/mprime, the highest-volume clients) stand ready to do (repeat) TF or P-1 not recorded, taking away from primality test throughput. Maybe not such an issue currently with gpus running typically 4 bit levels above the primenet threshold so providing some guard space, but still. Any unreported work done is a loss to the project.

Note, if R. Gerbicz' recent TF NF verification proposal is implemented in some reasonably effective way, the motivation for the no-factor, no-credit 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 no-verification reports. So forum-spammers would still have a way, and Madpoo's intervention would still be needed, during this transition period.

[Madpoo]

Originally Posted by SELROC

There is nothing wrong, it is only that I am now TF'ing at bit-levels where no factors are around. But the idea that all the energy spent will have a value of 0 is somewhat confusing.

I'll leave it to smarter folks to weigh in on that. If you're only doing TF to low levels (how low we talking, and were these already done to those bit levels?) I'm not sure.

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 factor-found 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.

Originally Posted by Madpoo

I'll leave it to smarter folks to weigh in on that. If you're only doing TF to low levels (how low we talking, and were these already done to those bit levels?) I'm not sure.

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 factor-found 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.

No absolutely. Only I was finding more factors when I requested assignments up to bit-level 76, so maybe I will restart doing that way.

[kriesel]

Originally Posted by R. Gerbicz

See the last table: https://en.wikipedia.org/wiki/Standard_deviation, ofcourse we have a different (binomial distribution) but for large N we are very close to this. Or you can get very quickly Probab(x<ev-5*sigma) for binomial distribution. So we'd fail this test only once per 3500000 p prime, because we're interested only in one side, if we have more than ev+5*sigma q primes then it isn't that interesting.

Make the decision per p,b and not per input file.

Ok. After thinking about it a bit more, and shifting frame of reference from confidence about one TF (p,b) report, to, how many false negatives do we want to design in, in all the millions of p,b combinations reported monthly, suddenly 5 or 6 sigma looks more appealing.

[Madpoo]

Originally Posted by SELROC

No absolutely. Only I was finding more factors when I requested assignments up to bit-level 76, so maybe I will restart doing that way.

I wouldn't worry about it.

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.

[ewmayer]

Originally Posted by Chuck

And of course the "emily" user link leads to a porn site.

Hey, don't blame the girl for being a natural multitasker!

Originally Posted by Madpoo

EDIT: "Samantha" appears to be in Stockholm... Meanwhile, I'm planning to just set each of those 5520 exponents back to the TF level they were at before and I'll just nuke all those bogus results.

This is like that Seinfeld episode involving the (fictitious) artsy-fartsy softcore film all the NYCers are raving about: "Rochelle-Rochelle: A Young Woman's Erotic Journey From Milan to Minsk". Here we would appear have the sequel, "Samantha-Emily: A Young TF-Troll's Erotic Journey From Stockholm to Chişinău".

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^(q-1) == 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 statistical-outlier approaches are interesting, as others have suggested we already have a super-simple 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 THz-years without finding any follow the same statistical probabilities as described for catching TF credit-fraudsters 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 factors-foound 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 expected-success-rate 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 TF-code build, methinks.

Originally Posted by chalsall

Lastly, since there would be no "reward" to the participant to submit the "No factor found" information, some _might_ simply not submit such results, thus making others redo the work with the resultant lower "success rate".

That is a very important point - how do we guard against mass assignment-abandonment/nonreporting under such a system? 2 suggestions:

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 number-outstanding below the server-set limit. The server updates your TF-probability-versus-expected number with each submission; once the count is high enough, too many sigmas outside the expected-success-rate gets you flagged to the sysadmin for "have a closer look at this user". Sysadmin will contact user re. possible hardware/bad-build problem if appropriate - if way-too-low success rate is due to such innocent causes, I'm sure the user will appreciate the heads-up.

2. Remember that TF is not our "last line of defense" prior to doing a full-bore primality test; all TF no-factors-found M(p) get p-1 factoring done prior to LL test. Each p-1 factor-found whose bit-ness is such that prior-TF 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 problem-hardware-or-software and TF-fraudster issues, both of which involve fairly simple - though by no means trivial - server-side enhancements.

[R. Gerbicz]

Originally Posted by ewmayer

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.

Wrong order. We would do a primality test (or say a base=5 pseudoprime test) for those q values only for that
(2^p mod q) mod 2^t = 1. Roughly we're expecting 2-4000 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 1-2000 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.

[kriesel]

Originally Posted by ewmayer

Careful - Not 'pseudoprime' in the sense that e.g. a^(q-1) == 1 (mod q), rather, "no factors up to some sieving bound", said bound typically 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.

I think you're being a bit generous there about what I wrote. Or tactfully filling a gap.

While the statistical-outlier approaches are interesting, as others have suggested we already have a super-simple 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 THz-years without finding any follow the same statistical probabilities as described for catching TF credit-fraudsters under the current system.

This would be a deterrent to tackling some of the testing explorations I've undertaken in the past. Gambling several thousand GhzD on a single exponent/bitlevel with a 1/80 chance of credit and factor is not the same as assured work credit plus a 1/80 chance of finding a factor.

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.

Primality tests deliver computing credit whether the result is primality (true or false), or composite (repeatable or mismatched residue, with or without error codes). The results may be imperfect and composite and yet they constitute progress toward finding the rare Mersenne prime. As does trial factoring a bit level or running a P-1 attempt.

So my vote is to simply change credit to factors-found 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 expected-success-rate 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 TF-code build, methinks.

The earlier unreliable hardware is clearly identified, the better. If obtaining the q list on a gpu goes wrong during a legit run, how do we distinguish that from faked results?

That is a very important point - how do we guard against mass assignment-abandonment/nonreporting under such a system? 2 suggestions:

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 number-outstanding below the server-set limit. The server updates your TF-probability-versus-expected number with each submission; once the count is high enough, too many sigmas outside the expected-success-rate gets you flagged to the sysadmin for "have a closer look at this user". Sysadmin will contact user re. possible hardware/bad-build problem if appropriate - if way-too-low success rate is due to such innocent causes, I'm sure the user will appreciate the heads-up.

2. Remember that TF is not our "last line of defense" prior to doing a full-bore primality test; all TF no-factors-found M(p) get p-1 factoring done prior to LL test. Each p-1 factor-found whose bit-ness is such that prior-TF should have turned up the factor raises a red flag.

So we have two pretty good ways of catching problem-hardware-or-software and TF-fraudster issues, both of which involve fairly simple - though by no means trivial - server-side enhancements.

As a user who's had gpus and cpus go bad, such an alert, or per user device breakdown would be welcome. I've been saying for a while, error rate per computer for a user would be a nice extension of the user results page. Unfortunately, since all gpus currently get lumped together into one manual virtual computer, that still doesn't support identifying a bad gpu.

Originally Posted by kriesel

Unfortunately, since all gpus currently get lumped together into one manual virtual computer, that still doesn't support identifying a bad gpu. .

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 RX580-0 and for gpu1 RX580-1, this should help distinguishing which gpu returned which result.

[chalsall]

Originally Posted by ewmayer

That is a very important point - how do we guard against mass assignment-abandonment/nonreporting under such a system? 2 suggestions:

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 number-outstanding below the server-set limit.

You might be forgetting that quite a lot of the TF'ing being done is not even reserved from Primenet. Those who are TF'ing just in front of the "wavefronts" are those most committed to the GIMPS project, and so actually reserve assignments, and are also the least likely to cheat.

Originally Posted by ewmayer

2. Remember that TF is not our "last line of defense" prior to doing a full-bore primality test; all TF no-factors-found M(p) get p-1 factoring done prior to LL test.

No, of course not. But the P-1 effort is lessoned the deeper a candidate is TF'ed. And TF'ing tends to find factors that P-1'ing won't (and vise versa).

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 ill-advised.