skipped bit levels

[tha]

Originally Posted by Madpoo

Whether Primenet should be modified to accept these "less than max" TF results, I don't know. I guess it couldn't hurt, but someone could take advantage of that to do a bunch of small TF work and hope for a lot of credit by doing tons of work over again, like factoring everything from 2^2 through 2^50 and flooding with results.

There is no point in the server accepting a factor that already has been found since all factors have been validated upon first reporting anyway. The server also wants LL-tests to be confirmed by a double check of the clients. Given the amount of factors I and others found due to redoing trial factoring and P-1 work the server should be accepting 'double checked trial factoring' as well in my opinion, even though that is not a guarantee that no errors were made twice. Technically double checked P-1 work is accepted already if the B1 and /or B2 bounds are higher. I think all reported work should be accepted.

[0PolarBearsHere]

Originally Posted by Madpoo

like factoring everything from 2^2 through 2^50 and flooding with results.

You get almost no credit for doing that. You can check for example... M915209387. When the job is done in a second, there isn't a lot of credit to be earned :P

[tha]

And let me add that credit should only be given to trial factoring work nor reported before or for a new factor.

[VictordeHolland]

Originally Posted by tha

And let me add that credit should only be given to trial factoring work nor reported before or for a new factor.

So you are saying: give people credit for doublechecking TF work (not very useful work if you ask me, unless there is clear suspicion the machine was producing errors) , but not for finding (additional) factors with TF?
I my opinion it should be the other way around!

[tha]

Originally Posted by tha

And let me add that credit should only be given to trial factoring work nor reported before or for a new factor.

Typo: NOT reported before

[Madpoo]

Originally Posted by tha

There is no point in the server accepting a factor that already has been found since all factors have been validated upon first reporting anyway.

I could be wrong but it sounded like the idea was to look for any new factors for exponents that have not yet had any factors found at all.

I guess if someone wanted to scan the "skipped' TF levels (which may not have been skipped, merely missing some data) and there's already a known factor, they're welcome to do so but seems like a waste of time to me.

The whole point I'm making is that just because there isn't a record of some particular bit level being done doesn't mean it wasn't really done. Non Prime95 clients seem to have been historically lax in reporting each stage of their progress up the TF ladder, and data from the old Primenet v4 days was a little spotty for certain non LL results. I'm referring to the raw result sent from the user which is exactly what we're talking about here.

Heck, you may have noticed that sometimes there's an entry in the LL result section for some exponent, but you can't find the corresponding entry in the history section of that page. Even after we recently added in a bunch of that old data, there are some gaps in the raw messages from clients. Doesn't bother me since the result itself (whether it's a residue, factor, ECM difficulty setting or P-1 bound info) is there.

But I get that some people see the gaps in the history that's displayed and it bothers them. I'm just saying, we can't assume the work wasn't really done. Maybe they didn't bother sending those "no factor found" lines to George and just sent the very last one for whatever max TF level they did... who knows. And then there were the clients that didn't say where they were starting their TF level, they only reported what they factored up to. How do we figure out where they started? Can't really say. Maybe they started one bit lower than the "to" line, but that would only be a guess.

See the dilemma? I just don't see a good way of saying "these exponents have missing TF ranges that should be re-done" with any type of certainty.

At best I could look for factors found by P-1 that *should* have been found by TF but weren't, but I already did that looking for particular users with bad track records of TF work, and there weren't any strong correlations.

It's all probably because the odds of finding a factor by TF are small anyway, so it's just hard to spot patterns. There's an average of how many TF attempts should result in a factor being found, but the std deviation seems to have a large range.

[dbaugh]

So, it sounds like TF work can be reported out of order but, TF work is not accepted that fills in the blanks. I almost understand not accepting any more TF work once a factor has been found for an exponent. However, this sounds like if someone did 73 to 74 for a bunch of exponents that had only previously been checked to 69 bits, only factors found by TFing the skipped bit levels would be accepted. The exponent status would say no factors found below 2^74, which is technically true, but implies there are none which may not be true. What a mess.

[Prime95]

TF work is only accepted in order. It has always been that way.

The full history section of an exponent report is sometimes incomplete. For example, all manually reported results prior to Oct. 2008 will not appear in the full history.

[dbaugh]

To be more specific, no factor TF work is only accepted in order. If TF work finds a factor then any previously unreported bit levels just leave a hole in the exponent report.

[Madpoo]

Originally Posted by dbaugh

So, it sounds like TF work can be reported out of order but, TF work is not accepted that fills in the blanks. I almost understand not accepting any more TF work once a factor has been found for an exponent. However, this sounds like if someone did 73 to 74 for a bunch of exponents that had only previously been checked to 69 bits, only factors found by TFing the skipped bit levels would be accepted. The exponent status would say no factors found below 2^74, which is technically true, but implies there are none which may not be true. What a mess.

That reminded me of the recent case (forget who reported it) where they had done a bunch of TF work and then found a factor at some bit level or another.

Just by pure randomness (I think these were manually reported), the entry for "factor found" came in earlier along with some of the "no factor between x and y". But one of the earlier "no factor" results came in after the rest, and it wasn't being accepted.

So that's another route by which TF work is being done but not showing up in the data.

Would it make sense to allow TF results for bit ranges lower than the max that's been done? Good question... I guess we'd have to consider what the cons are to that. The pros are that if people wanted to "fill the gaps", they could do so.

Cons? I'm trying to envision what that would look like on the server side. Will the server then be responsible for making sure there isn't an overlap or having to track every single bit level of each exponent, rather than just the max like it does now?

Or does the server even need to care? Example: if 20 different people want to run the exponent from TF 70 to 71, who cares, let's just record the data? Show it as a "throwaway" data point in the exponent history with whatever credit given to the user?

And then the potential for hijinks... would/could some user just report the same "no factor between X and Y" 100 times in a row and get a bunch of credit although it's the same work? So maybe it checks to make sure that same result, verbatim, wasn't already reported by that (or any other) user?

In a perfect world you don't have to worry about those things happening, but in the real world, people or computers will do unexpected things that you have to account for. LOL

[Mark Rose]

Originally Posted by Madpoo

Or does the server even need to care? Example: if 20 different people want to run the exponent from TF 70 to 71, who cares, let's just record the data?

That gets my vote.

Show it as a "throwaway" data point in the exponent history with whatever credit given to the user?

And then the potential for hijinks... would/could some user just report the same "no factor between X and Y" 100 times in a row and get a bunch of credit although it's the same work? So maybe it checks to make sure that same result, verbatim, wasn't already reported by that (or any other) user?

In a perfect world you don't have to worry about those things happening, but in the real world, people or computers will do unexpected things that you have to account for. LOL

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.