4776 and 4891 bites the dust.

and so does 8049

Remember that Quick ECM isn't 'free curves', it's just curves being run on someone else's computer. Running it a dozen times is wasting a lot of CPU time, even if it will sometimes find factors above 30 digits.
The sort of curves it runs are inefficient for finding 30+ digit factors, they're more suited to the 1520 range; e.g. the final curve (with [URL="http://www.mersenneforum.org/showpost.php?p=188677&postcount=563"]Quick ECM's params[/URL], which has B1=103971) has: (all the following results were found on my PC, from GMPECM with v, on a c79) [code]Expected time to find a factor of n digits: 20 25 30 35 14.84s 1.97m 22.92m 5.91h[/code]While the B1 sizes optimized for each of those digit levels (B1=11000, 50000, 250000, and 1000000, for 20, 25, 30, and 35 digit factors, respectively) is: (this was copy/pasted together, not originally a single output) [code]Expected time to find a factor of n digits: 20 25 30 35 10.41s 2.18m 18.37m 2.65h[/code]So clearly for any particular (mediumtolarge) size that you're looking for, Quick ECM isn't very efficient. Especially for 3035 digit factors. (remember that I took the final curve, when really it's 3 parallel runnings of 40 curves going from very small with a practically 0 chance of finding a 3035 digit factor to the one above) One thing I wasn't expecting was the result for 25 digits. Apparently having a B1 of about 100000 produces a lower expected time to find a 25digit factor than with a B1 of 50000! B1=103971 took 1172 ms and expects 101 runs to find a 25digit factor, for a total of 118.372 seconds, while 50000 took 594 ms and expects 214 runs, or 127.116 seconds. I thought the standard 11000, 50000, ... B1s were optimized to be the lowest times for their digit levels? Seems that it's not, at least for my computer. Now, if the computer it's running on (the DB server?) will idle otherwise, I say go ahead! :grin: But if it's getting other work done, I just hope you all realize that you're slowing that down in an inefficient way. [quote=gd_barnes;192075] Quick ECM is a great tool but it is a little quirky. Don't give up after trying it once or twice. I suspect there is some sort of built in curve randomizer so that it tries different curves each time you hit it. So you may try it 10 times with no luck but alas, it will factor it for you on the 11th try.[/quote] Of course. :smile: It just calls GMPECM (a.k.a. ecm.exe, the most widelyused ECM app), which uses a random sigma on each curve. 
[quote=MiniGeek;192099]One thing I wasn't expecting was the result for 25 digits. Apparently having a B1 of about 100000 produces a lower expected time to find a 25digit factor than with a B1 of 50000! B1=103971 took 1172 ms and expects 101 runs to find a 25digit factor, for a total of 118.372 seconds, while 50000 took 594 ms and expects 214 runs, or 127.116 seconds. I thought the standard 11000, 50000, ... B1s were optimized to be the lowest times for their digit levels? Seems that it's not, at least for my computer.[/quote]
those values were optimal at one point but improvements in ecm and in computers have changed what values are optimal check this [URL="http://www.mersenneforum.org/showthread.php?p=178923&highlight=curves#post178923"]post[/URL] out i might at somepoint write a program that will parse logs and find optimal values for higher digit levels 
[quote=kar_bon;192072][B]recommended to all users:[/B]
i saw the index 52 was a pure C93, so i tested it with the QuickECMoption of the FactoringDatabase. the first run turns it in P6*C87 the second run splitted the C87 into P20*P67! so please, try the great QuickECMoption before giving up! :grin: now it's at index 56 with a C96 (no more factors with QuickECM > next factor should be greater 30 digits)[/quote] Okay, I'll remember that next time. I'm not sure why I didn't do at least quick ECM for that particular one. :rolleyes: Meanwhile, extended [url=http://factordb.com/search.php?se=10&aq=8739&action=last20&fr=&to=]8739[/url] to i=50, size 83, on a C79 that wouldn't break after ~5 Quick ECMs. Same story for [url=http://factordb.com/search.php?se=10&aq=8873&action=last20&fr=&to=]8873[/url], now at i=48, size 88, C84. 
9027 terminates at step 48

[quote=gd_barnes;192081]There are a TON of C71's and C72's in the DB. (I got rid of all C<=70.) :smile: I would guess that 2030% of those will fast ECM. If not, then a quick msieve/yafu to factor them followed by fast ECM to advance them several more indexes will be quite effective. I think we're still a long way away from not being able to easily use fast ECM for home prime base 10 sequences <= 10200.[/quote]
i just did all c7173 most factored with fast ECM not even 2030% didn't continuing onward and upward 
7188 and 7282 Terminate

[quote=henryzz;192127]i just did all c7173
most factored with fast ECM not even 2030% didn't continuing onward and upward[/quote] Holy crap. I had to check for myself because that's a ton of pointing and clicking! I find it kind of addictive breaking up those bad boys. It's kind of fun isn't it? lol I see now that there are 5 sequences that are C<=73, which I'm sure people are in the middle of working on so I won't mess with them. Now here is what I expect you to do: Report every sequence here that you did so Karsten can update his page. (lol) Seriously, my feeling is that we should work on getting them all up to a "hard" C>=80, that is C>=80 that won't fast ECM. Tim, That's a good point on doing too many fast ECM's using up Syd's (or someone's) CPU cycles. I just remember from before when there were a lot of workers so there was apparently quite a bit available, which there isn't now. In the future, I'll limit the fast ECM's to 35 attempts. That's usually my limit but sometimes I lose count and end up doing 10 attempts. That was a good explanation on the curve randomizer. Now I kind of understand why fast ECM appears a little quirky at times. Gary 
[quote=henryzz;192127]i just did all c7173
most factored with fast ECM not even 2030% didn't continuing onward and upward[/quote] Since you did all those, did you find any primes? I would think you would have found several. One more thing: On the ones you did, did you continue fast ECMing subsequent indexes until you hit a tough one? If not, I take back what I said about it being a ton of work. lol 
I have seen that 6212 is finished.
For N<6212 c<80 done. 
All times are UTC. The time now is 19:41. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2021, Jelsoft Enterprises Ltd.