User TJAOI

[Anonuser]

Originally Posted by Prime95

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.

The following is probably well known (and it is unlikely that it has something to do with the missed factors), but I want to mention it for the sake of completeness:
Testing different bit ranges (but the same exponent) on different workers can lead to missed factors (because the workers can access the same save file).

An example (on a CPU with at least two cores/threads):
1. Put the following into worktodo.txt:

[Worker #1]
Factor=150003911,61,62

[Worker #2]
Factor=150003911,60,61

2. Start Prime95 and stop it before the second worker starts to do any work.
3. Next press "Continue..." and wait until both jobs are finished. This might result in two different no factor lines (but the second worker should find a factor).

[petrw1]

Originally Posted by TheMawn

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)

I've asked this question before....all factors submitted are double checked....via simple division I believe.

[petrw1]

Originally Posted by Anonuser

The following is probably well known (and it is unlikely that it has something to do with the missed factors), but I want to mention it for the sake of completeness:
Testing different bit ranges (but the same exponent) on different workers can lead to missed factors (because the workers can access the same save file).

An example (on a CPU with at least two cores/threads):
1. Put the following into worktodo.txt:

[Worker #1]
Factor=150003911,61,62

[Worker #2]
Factor=150003911,60,61

2. Start Prime95 and stop it before the second worker starts to do any work.
3. Next press "Continue..." and wait until both jobs are finished. This might result in two different no factor lines (but the second worker should find a factor).

If it's well known .... then I am out of the loop.
Curious how one would find such a bug.

As advertised....And since both workers returned the same checksum and finished at about the same time I suspect on the restart both workers were doing 61,62

[TheMawn]

Originally Posted by petrw1

I've asked this question before....all factors submitted are double checked....via simple division I believe.

Sorry for the confusion. What I meant was "Would a hardware or software bug that misses factors also be responsible for creating false factors?" which might give insight on errors in the past. For example, if one user reported several false factors, it could be a sign of bad hardware or software which may also indicate missed factors.

[LaurV]

Originally Posted by Prime95

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.

They were not, you are talking about Tjaoi's factors which are "first", and petrw1 was talking about my factors, which are not. After the last discussions here I queued all the 100M to 200M primes (with a pari line that writes to a file "factor=blabla,p,28,66", for all primes p in the range) to my misfitworktodo, and I found few hundred factors overnight, all in the range of 56 to 66 bits. I checked all of them, and NONE of them was a "first" factor (i.e. their mersenne corespondents were already known as composite, having smaller factors, part of them found by Tjaoi, part of them older). This activity continues, to 200M expos. I may queue to 300M, depends on the speed. I also did 990M to 1000M, I was thinking to start from the end (faster, shorter time) but there I had by mistake set the "stop after prime" to exit instead of going all the range. You can see I still found many "new" factors there too, but again, none of them was a "first". Then I decided to start "properly" from 100M.

It might be a P95 bug, but what I actually suspected can be a database "lost", after moving around from here to there, unfortunately I can't pinpoint it and it seems that a P95 bug around 55 bits is more probable.

edit: That is a kind of pity for all that work wasted to TF higher bits, fortunately is not much, TF for higher expos is faster. I would be curious if any "missing low factor" in the lower range, where LL time was lost... (but I won't try, here TF is painful).

[Prime95]

Originally Posted by TheMawn

If the old Prime95 versions are still archived, it would be a bit painful but possible to check them all.

The TF code hasn't changed in a decade. If the problem is due to a bug in prime95, the bug should still be there.

[bloodIce]

Similarly to LaurVs efforts, four days ago I started to re-factor with mfaktc exponents in M989900000-M990000000 range to TF65 (interestingly and luckily below LaurVs work). So far I have found only factors of exponents with previously known factors (about 11% of the factors were not reported before and new factors are all over 31 to 65 bits). I expect to find in total ~500 new factors. I do not see newly factored expos, but I will continue to search in another range when I finish this one or may be concentrate on pure double-check (re-factoring only exponents without known factors).

[snme2pm1]

Originally Posted by LaurV

It might be a P95 bug, but what I actually suspected can be a database "lost", after moving around from here to there, unfortunately I can't pinpoint it and it seems that a P95 bug around 55 bits is more probable.

At the risk of unhelpful speculation, might there there be some lost factors due to frequent server misadventure?
To seek clarity, should the lost factors have been known prior to public acceptance of work on affected exponents?

[lycorn]

Originally Posted by Prime95

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.

And one at 9M.
This series of factors was reported at a different time than usual, and it is much shorter than the ~daily reports of 3000+ factors, that are currently at 55.xxx bits. So they are actually working in ttwo different fronts. There is the systematic search by K, yielding no first factors, and these ranges that pop up from time to time, apparently focused on only one bit level, where the first factors are found. How systematic could this search be? As in, is this a guaranteed way of finding all missed factors? (Obviously assuming the hardware and software used by TJAOI are bug free). At least for this last report, and given that Primenet ranges from 9 to 900 M are represented, I would dare to say they tried the whole database, probably excepting some very low ranges, for 58-59 bit factors. That´s quite a job...

[lycorn]

Originally Posted by Anonuser

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

Now you may add:

2015-01-19_________________________58-59______________________85

[snme2pm1]

Originally Posted by lycorn

How systematic could this search be? As in, is this a guaranteed way of finding all missed factors? (Obviously assuming the hardware and software used by TJAOI are bug free).

It would be a whole more helpful if TJAOI et al made themselves public and announced the intent and rigor of their methodology.