skipped bit levels

[Mark Rose]

Yeah, the work involved for that batch was basically all duplicate work anyway, based on the only 1 factor found for 45 THz-days of work.

The 80 factors I've found in the last few days is about a 1.1% success rate, indicating virgin territory for skipped trial factoring. Perhaps credit is deserved there.

[ixfd64]

It some trial factoring at lower levels was not done correctly either. For example, an old result for M17458547 says it has no factors up to 65 bits, but TJAOI found a 63-bit factor: http://mersenne.org/M17458547

[Mark Rose]

I suppose I could do an analysis of the exponents TJAOI found and identify bad users. Madpoo could probably do a better job at that with direct access to the database.

[Gordon]

Originally Posted by Madpoo

I thought that was the server rejecting a TF result for *lower* bit ranges than what has already been checked in.

I think what Mark is suggesting is that if you tried to turn in results for 2^64 to 2^65 but there's no record of it being done from 2^63 to 2^64, it would pop up some message saying "hey, what about the lower range, do that first"

Nope, it's doing what I said it was. Try it, pick any exponent, then manually check in a result with the TF level higher than what is recorded.

In the example I gave, the db only showed factor attempt to bit 62, hence it rejected the 63-64 submission, but accepted the 62-63 one....

[dbaugh]

There is also the issue of skipped bit sub-levels. If one is doing TF on an exponent in say 2^68 to 2^69 and has it set to bail out if a factor is found, then that exponent has not truly been fully searched at that bit level. I have found several dual factors in a given bit level. Does exponent status have a way to distinguish finished searching results versus bailed out? I think it does. If so, then the bail outs need to be finished.

It all comes down to eliminating an exponent as quickly as possible versus developing a database of Mersenne factors.

[axn]

Originally Posted by dbaugh

If so, then the bail outs need to be finished.

If anyone is re-doing any TF, I would suggest to redo the whole exponent from scratch. For example, if you're planning to re-do bit level 68-69 for an exponent, redo the whole 0-69 range. It would take no more than 2x the time (probably much less), and will give some good assurance that there were no factors missed out due to <insert all possible reasons>

[bloodIce]

Originally Posted by axn

If anyone is re-doing any TF, I would suggest to redo the whole exponent from scratch. For example, if you're planning to re-do bit level 68-69 for an exponent, redo the whole 0-69 range. It would take no more than 2x the time (probably much less), and will give some good assurance that there were no factors missed out due to <insert all possible reasons>

There is absolutely no sense to re-do anything bellow TF59 or soon TF60. That is because of TJAOI's systematic work climbing slowly in the whole exponent space.
From very recently I do something that Madpoo is probably not very happy to see. I am re-doing all exponents in 900M range from TF60 to TF64 regardless if they have or not a factor. There is a chance to find a miss-reported exponent (did not happen so far) and obliviously a way to complete the database in this range to TF64. In my defense: TJAOI will do it anyhow soon. I have tried to do TF0-64 and there was nothing bellow TF59, which was not reported by TJAOI or someone else. I suggest that you do not spend time in less than TF60. As a little gratification to the effort (there is very little credit associated) you can see a small “bluefication” of the range in James' graphs (http://www.mersenne.ca/graphs/factor...M_20160309.png). Yeah, probably James is not that happy too.

[axn]

Originally Posted by bloodIce

There is absolutely no sense to re-do anything bellow TF59 or soon TF60. That is because of TJAOI's systematic work climbing slowly in the whole exponent space.

Unless TJAOI (or his software or hardware) has achieved godhood, consider them all to be fallible. Avoiding the lowest bit levels is false savings - they will get done almost instantly. Since the purpose is to make sure that we're catching all missed factors (for exponents that have been conclusively proven as prime), it is best to be thorough.

Anyway, not my cycles; just a suggestion.

[Mark Rose]

The lower bit levels are done almost instantly, but they have a large impact on GHzd/d. I've noticed this when redoing the various unreported bit levels.

[Gordon]

Originally Posted by dbaugh

... versus developing a database of Mersenne factors.

Some of us would like to see every candidate factored and are working to try and build such a list

[Madpoo]

Originally Posted by Dubslow

madpoo directly fiddled with the DB to add those results; PrimeNet (and its result submission process, which assigns credit etc) had nothing to do with it.

Of course the credit still deserves to be awarded, in some sense, though IIRC the participants (Mark Rose and madpoo primarily) had agreed that the credit wasn't of substantial importance and not worth the likely-large amount of manual work that would be needed to get it assigned. (It's probably doable, with some sort of hacking of the scripts to be run offline, but almost certainly more trouble than it's worth.)

I reserve the option to figure out how to appropriately apply credit later. Since I had to insert these records manually (they would have been rejected as unnecessary otherwise) I couldn't benefit from the credit calculations that the web code applies. I'm not familiar enough with how ghz-days is figured so for now I left it at zero.