RMA.NET

That's interesting, I had already made it so it is selected, but I didn't think of having the full form ready to input, for manual use.
This is easy todo.


Allright quit upstaging me. lol
Shane F.

[Flatlander]

25) Issue. At the moment clicking the icon moves/shrinks the form.

Oh no, the world is coming to an end, and the sky is falling!

I noticed the resize inconsistency.

[Flatlander]

I asked for that.

When approaching the end of the candidates, is it worth forcing newpgen to run at 1% CPU (or even close) even if more sieving is 'requested'. Seems silly to sieve for hours, then llr, when it would be quicker to just llr.

ie. (pseudo-code)

If (estimatedtimeleft) < (timer*1.5) then close(newpgen);

When approaching the end of the candidates, is it worth forcing newpgen to run at 1% CPU (or even close) even if more sieving is 'requested'. Seems silly to sieve for hours, then llr, when it would be quicker to just llr.
ie. (pseudo-code)
If (estimatedtimeleft) < (timer*1.5) then close(newpgen);

I understand your question, but don't know how you're applying it.
Approching the end, LLR would be at 99%, forcing NewPGen to 1%.
Only if sieving is faster at eliminating candidates, will it be requested at 99%.
It would be silly to test, when it's quicker to sieve, and vice versa. Right?

The psedudo code, gives me a better idea of your question.
Do you mean only at the end, or at the "point of no return", where NewPgen is completely not expected to come back?

The LLR finish time could be estimated, to force the last timer loop's with NewPGen closed. So that should be ok, but will only save <%1.
The point of no return, is hard with fixed k, since the variation is unknown.
This could be an optimization if acurately done, early enough for %1 to add up over time. This must not make a mistake though, and close Newpgen to early.

I've been running a large RMA.NET test for about 65 hours now.
k= 2145
n = 250000 thru 1250000
One million candidates of fixed k, RMAing.

NewPGen rate 1192 (dominant process)
LLR rate 200
Time period: 8 1/2 hours

[Flatlander]

Running fixed k = 31395 for n=205000 to 315000 for about 5 hours. NewPGen is dominant as expected, timer at 256.

Does 'Verbose' work for you?

You got me dead to rights.
This is my bug, I have two menu Verifies.
One of which writes Verbose=1 in the llr.ini file.
It should be hooked to it's proper menu option for Verbose.
I missed this proof reading the code, because verify and verbose looked the same.

Nice find!
I think Jean intended to now use this, for more of a diagnostic purpose.
Would'nt help much, if it does'nt work correctly due to me... hehe

I've Stopped a large RMA.NET test at about 68.19444 hours now.
k= 2145
n = 250000 thru 1250000
One million candidates of fixed k, RMAing.

NewPGen rate 723 (dominant process)
LLR rate 200
Time period: 8 1/2 hours


I'll resume this later, after the bulk of 0.9 is completed.

[Flatlander]

I am delighted to announce the birth of RMA.NET 0.8's firstborn.

After 2 days of labour came the birth of a slightly underweight '31395*2^208615-1'

Gifts of money may be sent via PayPal to my email account

RMA.NET version 0.83T is now available.
We need help testing the software on different target machines, before a release version is made.

The file can be found here, or downloaded as a group zip.
http://15k.us/aboutus.html