mersenne.ca

[James Heinrich]

Originally Posted by SethTro

Perfect I see it now (after I reloaded without cache).
I wrote some simple starting code for estimating factoring progress

I have adapted your code and added it. Do the numbers look sane?
Is there some simple translation to estimate probability of an undiscovered factor of <digits> length?
Is it interesting to extend the calculation/display lower/higher than 20/65 digits, and/or at smaller steps than 5 digits? If so all I would need is an updated data table.

[SethTro]

Originally Posted by James Heinrich

I have adapted your code and added it. Do the numbers look sane?

Looks good, I verified:
table doesn't show when no ECM
table doesn't show large digits when no (or few) curves have been complete
table seems to correctly counts curves

Few notes:
* Huge "Complete" numbers look a little silly but I don't have a suggestion on better UI.
* You could add a "Probability of missed (smaller) factor", the probability is
(1 - 1/curve_count) ^ curve_count
which can be transformed to
math.exp(curve_count * math.log(1 - 1/curve_count))
or approximated by
(1/e)^(complete)

Originally Posted by James Heinrich

Is there some simple translation to estimate probability of an undiscovered factor of <digits> length?
Is it interesting to extend the calculation/display lower/higher than 20/65 digits, and/or at smaller steps than 5 digits? If so all I would need is an updated data table.

Someone more versed in Mersenne theory can comment but in general I believe the https://en.wikipedia.org/wiki/Dickman_function tells us about the likelihood of finding a factor of a certain size, evaluating this function is hard, but I've seen code on this forum for it.

Originally Posted by James Heinrich

Is it interesting to extend the calculation/display lower/higher than 20/65 digits, and/or at smaller steps than 5 digits? If so all I would need is an updated data table.

The code I presented is a good starting spot. I suspect it's under estimating progress for larger digits by 10-30% (a guess) this is fine for me (as I just wanted a ballpark of progress) but if someone did want to improve they should take LaurV's suggestion and implement something that's aware of B2 instead of extending my/your current code.

[Viliam Furik]

A fellow Slovak GIMPS-er Anton Repko asked me to post his program, so here it is.

[James Heinrich]

Originally Posted by SethTro

You could add a "Probability of missed (smaller) factor", the probability is
(1 - 1/curve_count) ^ curve_count
which can be transformed to
math.exp(curve_count * math.log(1 - 1/curve_count))
or approximated by
(1/e)^(complete)

I'm sure I'm doing something wrong, but the first two versions give me an almost-but-not-quite-constant value of around 0.368 for everything.
The approximated third option seems (in my ignorant opinion) to produce "reasonable" numbers.
In each of the first two versions is it supposed to be the same "curve_count" used twice, or should one be the "expected" curves?

I've added the approximated value to the live server.

[SethTro]

Originally Posted by James Heinrich

I'm sure I'm doing something wrong, but the first two versions give me an almost-but-not-quite-constant value of around 0.368 for everything.
The approximated third option seems (in my ignorant opinion) to produce "reasonable" numbers.
In each of the first two versions is it supposed to be the same "curve_count" used twice, or should one be the "expected" curves?

I've added the approximated value to the live server.

Sorry should have been

(1 - 1/needed_curves) ^ curves_complete

[James Heinrich]

Originally Posted by SethTro

Looks good, I verified:
table doesn't show when no ECM
table doesn't show large digits when no (or few) curves have been complete
table seems to correctly counts curves
Huge "Complete" numbers look a little silly but I don't have a suggestion on better UI.

YAFU produces some output like this during its ECM stage:

fac: t15: 426.42
fac: t20: 246.52
fac: t25: 55.00
fac: t30: 8.75
fac: t35: 1.09
fac: t40: 0.11
fac: sum of completed work is t35.56

How would one "sum" those completion numbers (which I assume to be the same meaning as what I now have) to generate an overall "t-value"?

[James Heinrich]

There is a known issue with the nightly sync, will be processed when data is available.

[henryzz]

Originally Posted by James Heinrich

YAFU produces some output like this during its ECM stage:How would one "sum" those completion numbers (which I assume to be the same meaning as what I now have) to generate an overall "t-value"?

Binary search with different values?

[James Heinrich]

Originally Posted by henryzz

Binary search with different values?

No clue what you mean by that.

[James Heinrich]

Originally Posted by James Heinrich

There is a known issue with the nightly sync, will be processed when data is available.

Data should now be current.

[henryzz]

Originally Posted by James Heinrich

No clue what you mean by that.

Yafu has a function that tells it how many txx have been run. The number of digits (xx) which provides a value of 1 can be found using https://en.wikipedia.org/wiki/Bisection_method. This is also known as a binary search although strictly speaking that is for sets.

For example, if you know it is between t35 and t36 you would check if t35.5 has been completed. This restricts the search space to either t35 to t35.5 or t35.5 to t36. This can be repeated until you have the precision you want. The only assumptions are that the function must be continuous and monotone increasing or decreasing.