skipped bit levels - Page 3

kladner · 2015-12-13, 08:46

Quote:

Originally Posted by Mark Rose

That gets my vote.

It's simple if no credit is given. That's the situation that happens when the server does have a record of the work done. I, for one, would fill in the gaps.

Agreed. Unless this imposes significantly greater load on the server, why not just say, "Data is data."

dbaugh · 2015-12-13, 10:49

I would like to see gaps filled. Recording multiple rechecks of TF bit levels could get out of hand. I like credit but misleading exponent statuses concern me more.

LaurV · 2015-12-14, 09:39

My vote: no, on both accounts. Unless you find a method to scare off the credit hunters. If you allow that, I will follow a guy like Oliver who I know he is serious and really does his assignments and has a lot of gpu computing power, and I will report all the "no factor" results he checks in, as doublechecked by myself, without moving a single bit in my gpu, and get the credits. That's a promise!

Things are as they are for a reason.

I know that there are exceptional cases, and in that cases (dbaugh is one of the cases I am talking about) the user can PM Aaron or George and things can get fixed (like filling the gaps and get the credit, if you prove you did the work in that range at that time, or if you find George in good mood - the advantage is that other people like you won't waste time to doublecheck ranges already TF-ed, when "no factor" was reported). But don't forget the goal of the project is to find primes, and that there are factoring methods which don't find the factors "in order" (like P-1, ECM, and even TF, when you do more bitlevels in the same time, which is allowed for low bitlevels or if your card has memory to sieve it, or if you sieve on CPU, it will find the factors by class, and a 72 bit factor can be in a lower class and found out before 71 bit finishes). Therefore you must allow the factors to be reported "out of order" (no way around it!) and some idiot will always try to "fill the holes", without having any idea how P-1 works, for example, and try getting the credit.

So, by default, the TF "no factors" could be accepted out of order only if there is not a known factor. The duplicates "no factor" should not be accepted unless a method to scare the credit whores off is not implemented. Once a factor is found, no TF "no factor" should be accepted. Different situation for low P-1 or low ECM where complete factorizations are desired.

Special cases can be solved by PM to Madpoo or George. Like "hey, I did exponent xxxx from yy to zz bits and didn't find any factor, can you update the DB?". Possibly together with "hey, these are my log files".

Sorry for being bitchy, nothing personal.

kladner · 2015-12-14, 17:59

Quote:

Sorry for being bitchy, nothing personal.

I did not take it that way. You make good points.

dbaugh · 2015-12-14, 22:40

I agree with LaurV about duplicate TF. I disagree on the no TF accepted after a factor is found. If the only point of TF is to eliminate candidates for LL, then once a factor is found for an exponent using any method, no further results of any type should be accepted. Credit aside, I just want to see a record of any factors found and bit ranges that have been searched for factors so that we can know what work has already been done. Since there can be multiple factors in a bit range, having found a factor in a bit range does not mean that the range does not need to be searched.

LaurV · 2015-12-15, 03:09

Quote:

Originally Posted by dbaugh

I disagree on the no TF accepted after a factor is found.

Ok, but in this case we have to find a way to stop ignorant P-1-ers to report "no factors" below their factor level. We had cases in the past when a, say, 87 bit factor was found by P-1 and the assignee reported all xx to 86 bits as "no factor" because he didn't know that P-1 does not find the smallest factor, but the smoothest. How to avoid these cases in the future? (Or, are they so important to worth wasting the time? Maybe they are extremely rare?)

Mark Rose · 2015-12-15, 03:36

Quote:

Originally Posted by LaurV

Ok, but in this case we have to find a way to stop ignorant P-1-ers to report "no factors" below their factor level. We had cases in the past when a, say, 87 bit factor was found by P-1 and the assignee reported all xx to 86 bits as "no factor" because he didn't know that P-1 does not find the smallest factor, but the smoothest. How to avoid these cases in the future? (Or, are they so important to worth wasting the time? Maybe they are extremely rare?)

That can still be done today, just by manipulating the order of submitted results.

LaurV · 2015-12-15, 05:27

Quote:

Originally Posted by Mark Rose

That can still be done today, just by manipulating the order of submitted results.

Well, when a factor is found, it is usually sent out automatically. I don't send factors "by hand", and I wasn't thinking properly. But you are right, it can be done.

dbaugh · 2015-12-15, 05:44

If someone reported 12 bit range runs with no factors without actually doing the work they are going to miss some factors after a fairly small number of such results entries. These factors will likely be found at some point by P-1, ECM or duplicate TF. Then the jig is up. What happens if someone is caught doing such a thing?

If a person was corrupt and mad at GIMPS couldn't they have two IDs and fake enter LL and DC for a bunch of exponents and screw up the search for the next prime? There has to be some protection against this and so fake TF could be similarly protected against.

It looks like the only thing a person cannot lie about is a factor or a new prime.

dbaugh · 2015-12-15, 05:48

We should have pretty good stats by now on the frequency of factors of Mersenne exponents of various bit lengths. This could be used to identify likely fakers and to point to good hunting ranges (much lower than expected factors found).

VBCurtis · 2015-12-15, 06:15

Quote:

Originally Posted by dbaugh

We should have pretty good stats by now on the frequency of factors of Mersenne exponents of various bit lengths. This could be used to identify likely fakers and to point to good hunting ranges (much lower than expected factors found).

We don't need stats, as the distribution of factors is well known theoretically. as for your "they'll be caught soon enough"... why would ECM (or more P-1) be done on a number with a known factor? Or double-checking TF? At some point, someone might take interest, but likely not for years.

The red flag is reporting "no factor" levels well beyond normal depth, from the same user that reports a P-1 factor.

2015-12-14, 09:39	#25
LaurV Romulan Interpreter "name field" Jun 2011 Thailand 2×5,179 Posts	My vote: no, on both accounts. Unless you find a method to scare off the credit hunters. If you allow that, I will follow a guy like Oliver who I know he is serious and really does his assignments and has a lot of gpu computing power, and I will report all the "no factor" results he checks in, as doublechecked by myself, without moving a single bit in my gpu, and get the credits. That's a promise! Things are as they are for a reason. I know that there are exceptional cases, and in that cases (dbaugh is one of the cases I am talking about) the user can PM Aaron or George and things can get fixed (like filling the gaps and get the credit, if you prove you did the work in that range at that time, or if you find George in good mood - the advantage is that other people like you won't waste time to doublecheck ranges already TF-ed, when "no factor" was reported). But don't forget the goal of the project is to find primes, and that there are factoring methods which don't find the factors "in order" (like P-1, ECM, and even TF, when you do more bitlevels in the same time, which is allowed for low bitlevels or if your card has memory to sieve it, or if you sieve on CPU, it will find the factors by class, and a 72 bit factor can be in a lower class and found out before 71 bit finishes). Therefore you must allow the factors to be reported "out of order" (no way around it!) and some idiot will always try to "fill the holes", without having any idea how P-1 works, for example, and try getting the credit. So, by default, the TF "no factors" could be accepted out of order only if there is not a known factor. The duplicates "no factor" should not be accepted unless a method to scare the credit whores off is not implemented. Once a factor is found, no TF "no factor" should be accepted. Different situation for low P-1 or low ECM where complete factorizations are desired. Special cases can be solved by PM to Madpoo or George. Like "hey, I did exponent xxxx from yy to zz bits and didn't find any factor, can you update the DB?". Possibly together with "hey, these are my log files". Sorry for being bitchy, nothing personal. Last fiddled with by LaurV on 2015-12-14 at 09:43

2015-12-14, 22:40	#27
dbaugh Aug 2005 11² Posts	I agree with LaurV about duplicate TF. I disagree on the no TF accepted after a factor is found. If the only point of TF is to eliminate candidates for LL, then once a factor is found for an exponent using any method, no further results of any type should be accepted. Credit aside, I just want to see a record of any factors found and bit ranges that have been searched for factors so that we can know what work has already been done. Since there can be multiple factors in a bit range, having found a factor in a bit range does not mean that the range does not need to be searched. Last fiddled with by dbaugh on 2015-12-14 at 22:41 Reason: clarification

2015-12-15, 05:44	#31
dbaugh Aug 2005 121₁₀ Posts	If someone reported 12 bit range runs with no factors without actually doing the work they are going to miss some factors after a fairly small number of such results entries. These factors will likely be found at some point by P-1, ECM or duplicate TF. Then the jig is up. What happens if someone is caught doing such a thing? If a person was corrupt and mad at GIMPS couldn't they have two IDs and fake enter LL and DC for a bunch of exponents and screw up the search for the next prime? There has to be some protection against this and so fake TF could be similarly protected against. It looks like the only thing a person cannot lie about is a factor or a new prime. Last fiddled with by dbaugh on 2015-12-15 at 05:45 Reason: editorial

2015-12-15, 05:48	#32
dbaugh Aug 2005 11² Posts	We should have pretty good stats by now on the frequency of factors of Mersenne exponents of various bit lengths. This could be used to identify likely fakers and to point to good hunting ranges (much lower than expected factors found). Last fiddled with by dbaugh on 2015-12-15 at 05:54 Reason: more message

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Normalising rent levels	Bundu	Math	4	2017-09-27 06:14
Racism or low light levels or...?	jasong	jasong	2	2016-09-25 05:07
Missing bit levels?	NBtarheel_33	Data	6	2016-05-31 15:27
Is the data missing or did we miss a couple TF bit levels	petrw1	PrimeNet	2	2015-05-07 05:09
Recommended TF bit levels for M(>10^8)	NBtarheel_33	Math	19	2008-11-03 17:19

2015-12-13, 10:49	#24
dbaugh Aug 2005 11² Posts	I would like to see gaps filled. Recording multiple rechecks of TF bit levels could get out of hand. I like credit but misleading exponent statuses concern me more.