[QUOTE=petrw1;278013]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?[/QUOTE]

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.

[QUOTE=chalsall;277992]However, there is a second step where a separate script updates the "Assigned" SQL table and calculates the GHz Days credit.[/QUOTE]

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.... :smile:

[QUOTE=chalsall;278052]Thank you for the kind words. And thank you (and all the other workers) for using it.



Not at all. :smile:[/QUOTE]
Isn't all this politeness (bordering on the obsequious) a bit out of keeping with a few other threads typical around here?

[B]Long may it continue![/B]

David

[QUOTE=davieddy;278077]Isn't all this politeness (bordering on the obsequious) a bit out of keeping with a few other threads typical around here?[/QUOTE]

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

[QUOTE=Dubslow;277996]I'm pretty sure Prime95 weighs the overall chance of finding a factor for both TF and P-1 when calculating the bounds.[/QUOTE]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 ([URL]http://en.wikipedia.org/wiki/Dickman_function[/URL] , [URL]http://mathworld.wolfram.com/DickmanFunction.html[/URL]) 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 [I]L[/I] (with [I]L[/I] > TFed limit) is:

Probability of a smooth factor below [I]L[/I], using the Dickman function

minus

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

[quote]So if it's TF deeper, it has to do less P-1 to get the same chance of finding a factor.[/quote]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 [I]L[/I], ([I]L[/I] > 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.

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.)

[QUOTE=Dubslow;278091]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.)[/QUOTE]

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.

Optimizing factoring
 

Two points:

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

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

David

[QUOTE=davieddy;278111]Two points:

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

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

[QUOTE]2) Finding a factor is obviously better than proving a number composite.[/QUOTE]

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.

[QUOTE=Mr. P-1;278115]
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.[/QUOTE]

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

Something amiss with the GHz days calculation
 

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

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

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


Chuck