10+ table

[Batalov]

10,286+ c161 has now been factored and listed.

Logs will be attached later; the poly was new (E=1.1e-12), 30 bit lims, and the only noteworthy problem was that with 148M unique relations we couldn't get filtering to converge to any density (this is a fairly well known problem) and trimmed back to 130M unique relations which rapidly produced a small 4.16M² matrix with density 90 which was solved in under 21 hours.

[juno1369]

10,530LM are both done.

10,530M factors:
prp95: 22534789481525070481066146802824209631029690388674663333618185041786620876200193924826168812981
prp104: 33913181517084707700704620761515427690622077866060861977911749380448408900845560502173926937552593567761

Congratulations!

[Raman]

10,550M c201

1010050200803010030080200502011050200803010030080190401004017070301\
2042130350801402005020100603012041120300601002005020140803513042120\
3007017040100401908030100300802005011020050200803010030080200501001

plenty of zeros within its decimal representation.

as a snfs candidate,
for that number, the polynomials are upon each of that sides:->
Rational polynomial = (10^27)x - (10^55+1)
Algebraic polynomial = x^4+10x^3+10x^2-100x-100

the factors are respectively,

prp60 factor: 126239370797267198368490274128272780260464262689211651471701
prp141 factor: 800107125395206239935430877758693441879338279715986854168759198643184320615090047781735227652512476232674239391299478587112475352432305219301

Very much undersieved, built, rather struggled up with rather a larger sized matrix,
specified wall time for that job within that Leo cluster = 480 hours, that ran for upto 478 hours, 30 minutes.
Just very nearby to that threshold, simply, plus this is that first dependency when that factors were being returned up
Exactly 555 composite numbers, candidates, are being remaining up within that Cunningham tables, as of now,
right now, as well, only, actually

[juno1369]

10,750L is factored by yoyo@home using ECM and with
B1=26e7 and sigma=3307707165 (I got this information from Kurt Beschorner's website http://www.kurtbeschorner.de/),
here are the factors respectively:
prp59: 36605832263463437733314604426708004731796978480010361966001
prp127: 5772836960871551629739891702941582786046981888067577713935696090484780222936184202483806307259453794424863748245102369540143501



_______
Note that 1500L therein refers to the Phi_n10 classification. It is indeed 10,750L. --SB.

[Batalov]

Thanks, no need for the octic then.

[R.D. Silverman]

Originally Posted by juno1369

10,750L is factored by yoyo@home using ECM and with
B1=26e7 and sigma=3307707165 (I got this information from Kurt Beschorner's website http://www.kurtbeschorner.de/),
here are the factors respectively:
prp59: 36605832263463437733314604426708004731796978480010361966001
prp127: 5772836960871551629739891702941582786046981888067577713935696090484780222936184202483806307259453794424863748245102369540143501



_______
Note that 1500L therein refers to the Phi_n10 classification. It is indeed 10,750L. --SB.

It is very refreshing to see someone new contribute to the
Cunningham project. This saved quite a bit of SNFS time. Very nice.

[Batalov]

They have had increasing presence in repunits, and therefore some base 10 result was to be expected, sooner or later. Maybe they started a broader search (i.e. the cunnigham.in list), too. Good for them!

[Batalov]

Originally Posted by xilman; 2011/Apr/07

The factors of 10,334+ c166 are
256791351938897604127766524249910803570004341949762240760779741 (p63)
and
15082430268839895518120138007695651193149092773167884646166709770422465462163749312903859494420307404069 (p104).

It could almost be termed an ECM miss by Bruce's standards ;-)

Serge found the polynomial and performed 43.7% of the sieving. I did
the remainder of the sieving and ran the 6.74M matrix, which took 85
hours on a dual 4-core Xeon system. The factors appeared on the first
dependency.

Paul

(This was done on three home-type computers over a course of 3 weeks + a few days for post-processing. 6+6+4 cores.)

[bdodson]

Originally Posted by Batalov

(This was done on three home-type computers over a course of 3 weeks + a few days for post-processing. 6+6+4 cores.)

p63 doesn't make this a ecm miss (ignoring my friend PaulL = Xilman's
smilie). Who do we know that ran sufficiently many curves to find a
p63 to 62% chance? It didn't happen. Not even close. Nobody ran
that many curves on this number. If they had, they _shouldn't_have_;
relative to ecm effort as compared to the expect sieving effort.

One more time; it's not just factor size that makes an ecm miss,
but the number of ecm curves _actually_run [not what someone
imagines ought to have been run!!!] -- as compared to the sieve
runtime that makes an ecm miss. And even then 2-of-3 or 4-of-5
on 62% or 80% of a chance to find the factor (if there is one ...)

...-BD (Friday analysis ... better than your Monday analysis, as far
as anyone can see. Way better; how many curves did _you_ run?
Not enough, not even close to enough, I'm betting). -BD*

[xilman]

Originally Posted by bdodson

p63 doesn't make this a ecm miss (ignoring my friend PaulL = Xilman's
smilie).

It was a wink --- ironic teasing, in other words. Of course I didn't really expect you to have run so many curves that the final result was a true ECM miss.

That said, the reason Serge and I started this factorization was because Paul Zimmermann reported this factorization:

10,334+ c223 = p57 * c166 Zimmermann

Paul's p57 is not so much smaller than the p63. The vagaries of ECM could quite easily have found the p63 first, leaving the p57 to be found by us. Factors have certainly been found out of order before. I believe you've had successes of that nature.

Paul

[bdodson]

Originally Posted by xilman

It was a wink --- ironic teasing, in other words. Of course I didn't really expect you to have run so many curves that the final result was a true ECM miss.

That said, the reason Serge and I started this factorization was because Paul Zimmermann reported this factorization:

10,334+ c223 = p57 * c166 Zimmermann

Actually, now than I'm re-reading, how many curves does
one run on a c166? Is this 20% of the sieving time? Less
than 40%, for sure. So that's size/difficulty of the number
being factored; size of the prime found; and then number
of curves. What is the size of the factor we expect that
ecm can find (... to 62% or to 80% ...) in a c166 using 40%
of the sieving time?

I'd be inclined to bet that it's not sufficient for ecm to "find" even
the p57, much less the smallest p60.

Paul's p57 is not so much smaller than the p63. The vagaries of ECM could quite easily have found the p63 first, leaving the p57 to be found by us. Factors have certainly been found out of order before. I believe you've had successes of that nature.

Paul

Well, yes; of course. For my part, I appear to be spending too much
time/attention on curves counts. I certainly ought to know, even on
a Friday, that a Paul/Xilman analysis on any day of the week is probably
better than mine. Those pronouns "your/you" ought to have gotten a
rewrite ... uhm, like, "one's Monday analysis" ... "how many curves _were_
run" ... I'll be the one deserving banning, if I'm not more careful than
that.

On other topics, you might be astounded to hear that I've earned
gold "badges" from PrimeGrid for both Cullen and Woodall primes (without
having found any primes, of course; the searches are way out in
record range). And a "ruby" badge for sieving out composite GCW's.
I'm about to take our blade server's 32-bit xeons off of boinc, back
onto condor (and local user stat's). I was wondering whether you
have any inputs that don't require me to get an ecm server running?

-Bruce