Possible extention to the "GPU to 72 Tool" project?

[chalsall]

Originally Posted by petrw1

I apologize if this sounds like a dumb question but can't your spider also "spider" for the GHz Days that the Prime95 Server calculated?

Not a dumb question at all. Yes -- I could do that, but I've decided instead to use the equations which are already known rather than spider and parse yet another PrimeNet page.

[chalsall]

Originally Posted by chalsall

However, there is a second step where a separate script updates the "Assigned" SQL table and calculates the GHz Days credit.

OK, this has now been implemented, tested, proven sane, and added to the automated system. All the reports are showing the current status, and will automatically update.

So far, 20 P-1 tests have been run by six workers, with one factor found as a result. (Congrats monst!!!)

And thanks again to James for making the PHP code for GHz Days credit calculation so readily available. I just wish he worked in Perl....

[davieddy]

Originally Posted by chalsall

Thank you for the kind words. And thank you (and all the other workers) for using it.



Not at all.

Isn't all this politeness (bordering on the obsequious) a bit out of keeping with a few other threads typical around here?

Long may it continue!

David

[chalsall]

Originally Posted by davieddy

Isn't all this politeness (bordering on the obsequious) a bit out of keeping with a few other threads typical around here?

As a very good friend of mine told me many years ago: "Be responsible for the listening into which you are speaking".

[cheesehead]

Originally Posted by Dubslow

I'm pretty sure Prime95 weighs the overall chance of finding a factor for both TF and P-1 when calculating the bounds.

One of the parameters passed to Prime95's bounds-choosing algorithm for P-1 is the limit to which TF has already been done.

The algorithm uses the Dickman function (http://en.wikipedia.org/wiki/Dickman_function , http://mathworld.wolfram.com/DickmanFunction.html) to calculate the probability of finding a smooth factor up to a given limit. The way that the TF limit enters is that there is zero probability of finding a factor below the limit of TF already done. (If TF already found a factor, why are you here?) So, the probability of finding a smooth factor, for the purposes of the P-1 bounds-choosing algorithm, below a given limit L (with L > TFed limit) is:

Probability of a smooth factor below L, using the Dickman function

minus

Probability of a smooth factor below (the TFed limit), also using the Dickman function

So if it's TF deeper, it has to do less P-1 to get the same chance of finding a factor.

No, it's the other way around.

If TF is deeper (TF limit is higher), then the probability of P-1 finding a not-found-by-TF factor under a chosen limit L, (L > TFed limit), is lower. So, in order to have the same chance of finding a not-found-by-TF factor, the P-1 bounds have to be higher. But this increases the "cost" of the P-1, so that decreases the desirability of P-1 when balanced against the "cost" of further LL, which leads to choosing lower P-1 bounds.

[Dubslow]

I meant that P-1 has to do less work for an overall equal percentage, meaning if each exponent has a 5% factor limit and TF does 3% instead of 2, then P-1 only has to do 2% instead of three. (Of course those numbers are completely made up crap and you're post is still much more correct than anything I've posted.)

[Mr. P-1]

Originally Posted by Dubslow

I meant that P-1 has to do less work for an overall equal percentage, meaning if each exponent has a 5% factor limit and TF does 3% instead of 2, then P-1 only has to do 2% instead of three. (Of course those numbers are completely made up crap and you're post is still much more correct than anything I've posted.)

You are correct that, in order to have an equal overall chance of finding a factor, if there is more TF then there will be less P-1 work done.

But this is not what the P-1 bounds calculation is trying to determine. Rather, the algorithm seeks to maximise the expected time LL time saved, (i,e. the probability of success times the time to do the LL(s)) less the time of the P-1 computation itself. As the bounds (and consequently the computation time) increases, so does the probability. But the law of diminishing returns applies. P95 chooses limits at the point where the expected benefit of doing one more iteration of either stage 1 and stage 2 falls to equal the cost of doing that iteration.

If more TF has been done, then the benefit of doing P-1 is reduced, and this crossover point is reached sooner, hence more TF implies less P-1. This has nothing to do with equalising the overall probability of success.

[davieddy]

Two points:

1) Near optimum, a tadge off makes little difference.
A good example is that no-one around here questions
the "bitlevel" as a sensible granularity for TF

2) Finding a factor is obviously better than proving a number composite.

David

[Mr. P-1]

Originally Posted by davieddy

Two points:

1) Near optimum, a tadge off makes little difference.
A good example is that no-one around here questions
the "bitlevel" as a sensible granularity for TF

Indeed. The P-1 bounds calculating algorithm uses various approximations and at least one outright guess.

2) Finding a factor is obviously better than proving a number composite.

That's a matter of opinion, albeit one I agree with. How much value, over two matching LLs to place on a factor is a matter of personal choice. The algorithms assume none.

[davieddy]

Originally Posted by Mr. P-1

That's a matter of opinion, albeit one I agree with. How much value, over two matching LLs to place on a factor is a matter of personal choice. The algorithms assume none.

I think everyone here is of that opinion.
While we all have faith in the validity of LL
(Some of us even understand why it works)
there seems to be a number who get an erection
every time they find a factor.

David

[Chuck]

Last night it gave me 2,533.628 GHz days credit for exponent 48276133 and indicates I found a factor. Gimps says

Manual testing 48276133 NF 2011-11-13 00:06no factor for M48276133 from 2^70 to 2^71 4.9533

Manual testing 48276133 NF 2011-11-13 00:06no factor for M48276133 from 2^69 to 2^70 2.4767


Chuck