skipped bit levels

[lycorn]

Originally Posted by Madpoo

if an exponent already has a factor, there isn't a process in place to keep track of the cumulative "difficulty" level from P-1 or ECM work... as in, the measure of how many curves at what bounds, etc.

I don´t think that´s entirely correct, at least as ECM goes. The "ECM Progress" page has a section where results (number of curves and B1 bounds) are recorded for exponents that already have known factors.

[chalsall]

Originally Posted by ixfd64

I find Chris' credit calculator to be pretty accurate.

That's James'....

[Mark Rose]

Originally Posted by Prime95

As far as I know, the server has never accepted TF results that are out of order. It still doesn't. For example, if a number is factored to 2^70 and you report no factor from 2^71 to 2^72, then you will get an error and the number will still show as factored to 2^70.

Then there may be a bug. I tested again last night with M536,339,813. I reported the 2^67 to 2^68 work first, which was accepted, then the 2^66 to 2^67 work, which was also accepted.

The two 2^67 to 2^68 lines seems to be a race condition: I was manually submitted at the exact second mfloop.py was submitting the result.

When I look at my account results, it appears I was given credit for all those lines.

What did the recent change do? Out-of-order and unneeded TF as well as unneeded P-1 results are now recorded in the full history with no CPU credit. This will allow those that are trying to find factors of Mersenne numbers that already have known factor(s) to keep a record of their efforts.

Very much appreciated!

The change also allows us to bump the how-far-factored value when a hole (no factor from 2^70 to 2^71 in the example above) gets filled. This is not implemented and there are no plans to do this.

I had found a couple dozen exponents in this state late last year and "fixed" the database by trial factoring one bit more. I see now that my test exponent is now in that state.

[ixfd64]

Originally Posted by chalsall

That's James'....

Argh, I always get confused between you two. LOL.

[Prime95]

Originally Posted by Mark Rose

Then there may be a bug. I tested again last night with M536,339,813. I reported the 2^67 to 2^68 work first, which was accepted, then the 2^66 to 2^67 work, which was also accepted.

The two 2^67 to 2^68 lines seems to be a race condition: I was manually submitted at the exact second mfloop.py was submitting the result.

When I look at my account results, it appears I was given credit for all those lines.

Please resubmit the 2^67 to 2^68 line as the exponent is only marked as factored to 2^67.

There could well be a bug regarding CPU credit, which of course is not really a big deal. There is PHP code in there that does give CPU credit for unneeded work where you have a valid assignment. The PHP code is there so that you get CPU credit when someone poaches an assignment. The code might also give you CPU credit for the out-of-order results when you have a valid assignment.

[Prime95]

Originally Posted by lycorn

I don´t think that´s entirely correct, at least as ECM goes. The "ECM Progress" page has a section where results (number of curves and B1 bounds) are recorded for exponents that already have known factors.

Agreed. ECM work is accepted and properly tracked for Mersenne numbers with known factors if the Mersenne exponent is small (less than 20M????). If that limit is less than 20M. it shouldn't be hard to change....just let me know.

[Mark Rose]

Originally Posted by Prime95

Please resubmit the 2^67 to 2^68 line as the exponent is only marked as factored to 2^67.

Done. That accepted the line and bumped the factored-to number. Gave me 0.0557 GHz-days.

There could well be a bug regarding CPU credit, which of course is not really a big deal. There is PHP code in there that does give CPU credit for unneeded work where you have a valid assignment. The PHP code is there so that you get CPU credit when someone poaches an assignment. The code might also give you CPU credit for the out-of-order results when you have a valid assignment.

That makes sense. I did have a valid assignment using /manual_gpu_assignment.

[Madpoo]

Originally Posted by Prime95

Agreed. ECM work is accepted and properly tracked for Mersenne numbers with known factors if the Mersenne exponent is small (less than 20M????). If that limit is less than 20M. it shouldn't be hard to change....just let me know.

My mistake on the ECM. Yeah, the stuff from Alpertron is all P-1, but on smaller numbers:
16,359 below 1M
25,900 between 1M and 2M
2,163 between 2M and 2.06M
2 random ones at 7.7M and 9.3M

I don't question the worth of doing P-1 at all on the smaller stuff, compared to ECM... what's done is done.

ECM work, as George mentioned, is indeed tracked even after factors are found.

[alpertron]

Originally Posted by Madpoo

My mistake on the ECM. Yeah, the stuff from Alpertron is all P-1, but on smaller numbers:
16,359 below 1M
25,900 between 1M and 2M
2,163 between 2M and 2.06M
2 random ones at 7.7M and 9.3M

I don't question the worth of doing P-1 at all on the smaller stuff, compared to ECM... what's done is done.

ECM work, as George mentioned, is indeed tracked even after factors are found.

One run of P-1 with given bounds B1 and B2 has the same probability of finding a factor than running an ECM curve with the same bounds. But P-1 is about 10 times faster than ECM.

So for numbers with almost no ECM done, like the ones I sent to you, I can find more prime factors than ECM in the same time.

Notice that all work was done on Mersenne numbers with at least one prime factor known.