User TJAOI

[Anonuser]

Originally Posted by petrw1

--- What bit ranges (maybe 55-56 only???)

It seems that at least 5 different bit ranges are involved (after taking the following exponents into account).

274992953 287090333 313095199 362178347 428160451 456904421 511225397 530868347 557137307 636837569 734006137 752732219

(It might also be worth mentioning 788028821). To summarize some of TJAOI's activities (based on the data presented so far):

submission date (yyyy-mm-dd)_____bit range of factors_____number of cleared exponents

2014-03-24_________________________53-54______________________12
2014-04-16_________________________54-55______________________27
2014-05-30_________________________55-56______________________61
2014-08-21_________________________56-57______________________51
2014-11-14_________________________57-58______________________60

[TheMawn]

Originally Posted by Anonuser

submission date (yyyy-mm-dd)_____bit range of factors_____number of cleared exponents

2014-03-24_________________________53-54______________________12
2014-04-16_________________________54-55______________________27
2014-05-30_________________________55-56______________________61
2014-08-21_________________________56-57______________________51
2014-11-14_________________________57-58______________________60

This is an immense amount of saved work, even if we found these with P-1 early-ish on. Of course there is the fact that a lot of these aren't going to be getting LL tests in the foreseeable future, but still.

[petrw1]

Originally Posted by Anonuser

2014-11-14_________________________57-58______________________60

Any yet over 58 ... or is he not there yet?

It could be that they were missed in the pre-sieving.

When PrimeNet v5 was released and the exponent base was increased from 73.9M to 1B there were many ranges with NO factoring stats to indicate factoring NOT started.
Again I could be wrong but I recall that factoring assignments for these ranges started at 58+ bits.

[Anonuser]

Originally Posted by petrw1

Any yet over 58 ... or is he not there yet?

Not that I know of. But if there is any work in progress it is probably not finished yet.

On another note: I have found the following exponents (they have been cleared by P-1, but they should have been cleared earlier).

68723147 72007723 64254121 66558353 66646717 66656749 66826681 68075017 68389943 68621681 68781347
69117571 69410291 69858031 70512983 70685837 70902553 71169949 71293009 71964917 72823183 78513509

It seems that all the factors were missed by the same user. It might be a good idea to recheck the TF work that has been done by this user.
@owftheevil: Are the first two exponents (68723147 and 72007723) the ones that you had in mind?


A few other examples of factors that were missed by other users (and that have later been found by P-1):

53043031 53430761 53433521 58145281 58273277 58294177 58577543 58720187 60219487 61036883 65922127 66189911 66543011

[petrw1]

Several exponents in this list start in the status with the line

No factor to 2^64

I don't think this means from 2^2 to 2^64 but rather from something more like 2^58 ish.

Now that we are seeing that some of the missing factors are in the mid to high 60 bit range that tells me they weren't missed due to a bug in an old version of Prime95 (I'm going to guess those that missed the factors were NOT all running some very old buggy version).

A question like this was posed a few times in the past:

"Granted it is easy to verify that a factor found message is truly a factor. But how can you be certain that a 'no factor from ...' message is accurate and didn't miss any factors?"

Seems there isn't really any way to be sure.

[Prime95]

I can think of 3 things we should be looking into:

1) Is there a prime95 bug? I think, there are at least 2 major TF paths, SSE2 and non-SSE2. However, I may not have written SSE2 code for TF below 2^64. Fixing such a bug isn't important, but understanding it might let us greatly reduce the amount of work retesting exponents.
2) Going forward, should we consider an mfaktc/o option that re-TFs some of the lower bit levels? To re-TF from 2^54 - 2^65(?) is a pittance compared to TF from 2^73 to 2^74.
3) Or should we consider a GPU project that re-TFs 2^54-2^6x? I'm leaning towards no -- I suspect there is a great deal of overhead in setting up an exponent in mfaktc vs. the time it takes to actually do the TF vs. the number of factors you are likely to find. We can let TJAOI continue on. He'll probably be into the low to mid 60s by the time GIMPS is thinking about LL on exponents above 100M.

[lycorn]

Another bunch of first factors just popped up in the Recent Cleared report. For numbers with exponents ranging from 9M to well in the 900M ranges. Factors are all between 58 and 59 bits, and many umbers had already been TFed to the mid/high 60s and some to the low 70s. What a waste!

[petrw1]

Originally Posted by lycorn

Another bunch of first factors just popped up in the Recent Cleared report. For numbers with exponents ranging from 9M to well in the 900M ranges. Factors are all between 58 and 59 bits, and many umbers had already been TFed to the mid/high 60s and some to the low 70s. What a waste!

TJAOI continue to find HUNDREDS of factors in the 50-58 bit range.
The big question if how many of these are "first factors" for an exponent. Can you tell easily? I can't without querying each one individually.
The vast majority are not ... but a few are. And these expose the wasted deeper TF that has been happening.

Anonuser has done good analysis pointing these FIRST factors out.

P.S. <BUMP> I had proposed a couple weeks ago that the Web Reports of Results Cleared indicate if it is a First, Subsequent or Last factor found. I suspect at the time it is reported there it might be relatively easy to determine which it is.

I see LaurV found several as well in this range. Spot checking a couple they are NOT FIRST factors but they are still missed as they are at a bit level lower than the current TF level.

[Mark Rose]

Originally Posted by Prime95

3) Or should we consider a GPU project that re-TFs 2^54-2^6x? I'm leaning towards no -- I suspect there is a great deal of overhead in setting up an exponent in mfaktc vs. the time it takes to actually do the TF vs. the number of factors you are likely to find.

The overhead isn't so bad. On a GT 430, I can TF 42180727 from 54 to 65 in 11 minutes in a single pass, so a single setup per exponent. Mind you, I get much lower GHz-d/d throughput than achieved in higher bit depths.

[Prime95]

Originally Posted by petrw1

Spot checking a couple they are NOT FIRST factors but they are still missed as they are at a bit level lower than the current TF level.

I spot checked those in the "recently cleared" report and they were all FIRST factors. One was at 28 million. The rest all above 95 million.

[TheMawn]

The bugs are buggy software is easy to find. For any factor TJAOI found, run that range and exponent and see if the factor is found or not.

If the old Prime95 versions are still archived, it would be a bit painful but possible to check them all. It becomes more complicated if other software was used.

I still think we need a more structured approach than the checking Anonuser did. It was an extremely valuable find, but I think we'd be better off having a list of EVERY missed factor. The biggest thing to check is the other history for that exponent: When should that factor have been found? mfaktx has been in play for a good while, (and please correct me if I am wrong) but am I not correct in saying that the GPU's have not been involved in the ranges so far worked by TJAOI?

Because there seems to be little or no history of factoring between 2*P + 1 <= q <= 2^6X it is hard to know the approximate time that, say, the 2⁵⁷ - 2⁵⁸ should have been worked and know which versions of Prime95 were trendy at that time.

The trick will be to find the bug itself and identify the category of exponents and / or factors vulnerable to it.


Could there also be the possibility of faulty hardware? If the sieving was done by just a handful of people, that could be a possibility, but it leaves us completely in the dark.

EDIT: (Is there a chance that the same faulty hardware and / or bugs could generate false factors? I would be impressed if all the old submission logs are still hiding somewhere, but if they were, one could look for numbers falsely submitted as factors? I'm not sure if that information would even be of any value)