ECM probabilities and bit levels

[PhilF]

Originally Posted by chalsall

Or by the instance, for instance...

Thanks for the information.

Interestingly, I have found this to (kinda) not be true.

On my local machine, an instance of Prime95 running ECM curves does indeed update the save file(s) when it is interrupted.

However, with mprime running curves on Colab with Google Drive connected and used for storage, the save files(s) are not updated upon a program interruption.

This behavior might be different with other types of save files.

[chalsall]

Originally Posted by PhilF

However, with mprime running curves on Colab with Google Drive connected and used for storage, the save files(s) are not updated upon a program interruption.

Are you talking about clicking the "Running" button, thus interrupting the "job"? Or are you talking about when an instance is killed?

If the latter... My observations (under both Colab and Kaggle) are that the "kills" are instant (and painless). No notification by way of SIGINT, SIGHUP, etc. It's like a virtual plug is pulled out of the wall kinda situation.

I remember under AWS/EC2 there was a way of getting something like a two minute warning for their interruptable instances. Definitely not here.

[PhilF]

Originally Posted by chalsall

Are you talking about clicking the "Running" button, thus interrupting the "job"? Or are you talking about when an instance is killed?

If the latter... My observations (under both Colab and Kaggle) are that the "kills" are instant (and painless). No notification by way of SIGINT, SIGHUP, etc. It's like a virtual plug is pulled out of the wall kinda situation.

I remember under AWS/EC2 there was a way of getting something like a two minute warning for their interruptable instances. Definitely not here.

I am indeed referring to clicking the running button. I have found that when it is clicked, the connection to your Google Drive is instantly severed. So even though Prime95 shows the normal termination message, I think it never has a chance to update the save files.

[VBCurtis]

Originally Posted by mnd9

Just another quick follow up probability question: so say an exponent has the expected B1=50k and B1=250k curves done, is the overall probability of missing a factor less than 30 digits still 1/e or a bit lower? In other words do the 50k curves contribute some additional effort independent of the 250k curves or is the 1/e estimate under the assumption that appropriate curves have been run at lower B1 values as well?

Smaller curves contribute nothing meaningful to the larger digit level, less than 15% of the work (compare 1/e^1.14 to 1/e for a more accurate estimate of the effect of 50k curves on 30-digit level including 250k curves). The reverse is not true, though- completing the 250k-level curves is about 6 times the work of the 50k curves, and reduces the chances of a missed 25-digit factor to 1/e^7 (roughly).

That is, larger-bound curves also find factors smaller than the targeted size. That's why we move forward into larger bounds even when there's a 1/e chance we missed a factor; the larger curves will find it, while also having a chance to find larger factors.

[LaurV]

I think OP's question was more along the line "why don't we do directly the B1=250k curves, if the smaller don't contribute to the probability?". But if you play a while with ECM and count how long one curve at each level takes, you see why.

[chalsall]

Originally Posted by LaurV

But if you play a while with ECM and count how long one curve at each level takes, you see why.

I shouldn't be up, but I am...

I ran an experimental ECM from Primenet's Manual assignment page -- got 13082789,-1,50000,5000000,50. One curve took ~35 minutes on a i5-7400 @ 3G. Likes it's memory -- used something like 8GB during stage 2. Checkpoints were 3.2M.

Quick question: is there any problem submitting a smaller number of curves than assigned? I understand there's no "toe-stepping" here -- every curve is run from a random seed. I'm more wondering about the server-side of things -- is it going to pollute the Primenet DB table(s) with a needless level of record keeping?

An initial impression is this should be fairly trivial to deploy in a "percisistanceless payload" style setting. The checkpoints are small enough to not be a problem sending back every 30 or even 10 minutes.

The CPUs available, while GPUs are running, are going to take something like two hours or so on a similar job, so there's no chance the requested 50 curves are going to run during one instance lifetime (or several, for that matter).

[LaurV]

Can't answer about how overloaded the server will be with that (probably insignificant, but server's gods have to confirm that), but technically there is no problem in reporting more or less curves than you reserved. I did this in the past (reporting one curve, or 10, when I was reserving the default 3). The assignment is gone when the assigned number is fulfilled.

[lycorn]

Originally Posted by PhilF

I am indeed referring to clicking the running button. I have found that when it is clicked, the connection to your Google Drive is instantly severed. So even though Prime95 shows the normal termination message, I think it never has a chance to update the save files.

True. I note the same (and loose some work due to that) every time an instance is killed/stopped, either because the allowed time limit is reached or I click the running button.
The default saving interval is 30 minutes, but I have already lowered it to 10 to reduce the chances of loosing a substancial amount of work. It can be done adding the line DiskWriteTime=nn to the prime.txt file, resident in the mprime folder.

Originally Posted by Chalsall

OK. And am I inferring correctly from your statement that this is "non-nominal" work?

Yes, absolutely. Virtually all the work I´m currently doing is non-nominal. You know, after 17 years with the GIMPS project you feel like being a bit "creative" to avooid getting tired, so I started setting some personal goals and change them from time to time, depending on my mood and, of course, available resources.

[R.D. Silverman]

Originally Posted by mnd9

Hi all,

I'm getting into doing more ECM work and I'm wondering -- if the expected number of curves indicated for Prime95 (e.g. 280 curves at B1=50k, 640 curves at B1=250k) are run, and no factor is found, what is the probability that we can exclude a factor in that digit range? In other words, is performing the expected number of curves, the equivalent of a "no factor found" TF result for a specific bit range?

Also does anybody have a rough breakdown of what bit level each B1 level corresponds to? I understand that according to this page https://www.alpertron.com.ar/ECM.HTM that for example B1 of 50000 is the 25 digits, 250000 is 30 digits, so is it just as simple as multiplying these values by ln(10)/ln(2) or ~3.3?

Thanks!

See:

https://www.ams.org/journals/mcom/19...993-1122078-7/

"A Practical Analysis of The Elliptic Curve Factoring Algorithm"

It tells you everything you might ask.

BTW, I would include the .pdf in this post, but I don't know how to insert the
whole .pdf file.

[chalsall]

Originally Posted by PhilF

I am indeed referring to clicking the running button. I have found that when it is clicked, the connection to your Google Drive is instantly severed.

Really??? Just interrupting (Click on running icon, "Cntl-M I", Runtime menu -> Interrupt execution) the Section's run causes an unmounting of the Drive?

Why? That sounds like a design flaw to me.

I haven't actually attached a drive to an instance for several weeks. I now have a "throw-away" account I can use to run some experiments. Over the weekend I'll look at this, as well as test if "rm -rf /content/drive/" does what I think it might...