6+ table
[code]Size Base Index Mod Diff Ratio
261 6 419 + 326 0.798 246 6 421 + 327.6 0.749 331 6 431 + 335.3 0.985 258 6 436 + 339.2 0.758 270 6 439 + 341.6 0.788 282 6 443 + 344.7 0.816 289 6 448 + 298.8 0.965 /7/resvd 283 6 449 + 349.3 0.807 311 6 454 + 353.2 0.878 344 6 457 + 355.6 0.965 336 6 458 + 356.3 0.941 280 6 461 + 358.7 0.8 327 6 463 + 360.2 0.906 311 6 464 + 361 0.859 320 6 466 + 362.6 0.881 312 6 472 + 367.2 0.848 281 6 473 + 334.6 0.838 /11q 338 6 478 + 371.9 0.907 309 6 479 + 372.7 0.827 337 6 481 + 345.4 0.973 /13 268 6 482 + 375 0.713 307 6 484 + 342.3 0.895 /11q 282 6 488 + 379.7 0.741 330 6 493 + 383.6 0.858 316 6 494 + 354.8 0.889 /13 315 6 496 + 385.9 0.814 258 6 497 + 331.4 0.776 /7 294 6 499 + 388.2 0.75 [/code] 
GMPECM 6.0.1 curves run on 6,762M (with default B2):
4362 curves with B1 = 11e6 6791 curves with B1 = 43e6 15504 curves with B1 = 11e7 Jon 
6,363+ C172 = P75.P98
P75=103373476033477388263515282957106895317857131511194597652434632687520479231 This was done with ggnfs0.77.1 using polynomial 36x^66x^3+1, 28 bit large primes, and algebraic/rational factor base limits of 14.8/16 million. 
6,287+ C154 = P66.P88
P66=247859037729470996906245243451923112548845447499779115951590660463 This was by SNFS (difficulty 191.4) with ggnfs0.77.1, using polynomial x^6x^5+x^4x^3+x^2x+1, 28 bit large primes, and algebraic/rational factor base limits of 14.7/20 million. Sieving took 66 GHz days on a mix of P2,P3,P4 CPUs, linear algebra took 10 GHz days on a P4, peak RAM usage was 714 MB. 
6,798L C140 = P57 * P84
P57 = 286227504202337752215096844369178117421662207554962805489 This was by GNFS with ggnfs CVS 20060310 using 28 bit large primes and algebraic/rational factor base limits of 14.1/14.0 million. Polynomial search took 9 GHz days on a P4/Celeron, sieving took 93 GHz days on a mix of P2,P3,P4 CPUs, linear algebra (on the third attempt) took 11 GHz days on a P4. Peak RAM usage was about 850 MB. 
factorization of 6^369+1
The factorization of 6^369+1
[CODE]N=1995318523583569410536518710238825992069432091418126270747301312022729565418312904399527685768670754705838744041545211857263269211105325133582097428175392915125238452242062431167 ( 178 digits) SNFS difficulty: 191 digits. Divisors found: r1=13962920965423422985070859383439633233088296131740062300197159 (pp62) r2=142901225934358910616458334546032475881108357631878872140161426564856550164076857572859982163043154061736815224575913 (pp117)[/CODE] 
[QUOTE=smh;92575]The factorization of 6^369+1
[CODE]N=1995318523583569410536518710238825992069432091418126270747301312022729565418312904399527685768670754705838744041545211857263269211105325133582097428175392915125238452242062431167 ( 178 digits) SNFS difficulty: 191 digits. Divisors found: r1=13962920965423422985070859383439633233088296131740062300197159 (pp62) r2=142901225934358910616458334546032475881108357631878872140161426564856550164076857572859982163043154061736815224575913 (pp117)[/CODE][/QUOTE] Nice one. Sam's news letter arrived here this morning. Not sure whether you've received yours yet. Paul 
[QUOTE=xilman;92607]Sam's news letter arrived here this morning. Not sure whether you've received yours yet.[/QUOTE]Only a confirmation that he recieved the factors.
I guess i have to ask prof. Wagstaff to be included in this mailing list? 
156=53+103
[QUOTE=garo;48285][CODE]Base Index Size 11M(45digits) 43M(50digits) 110M(55digits) 260M(60digits) Decimal
... 6 337+ C156 0(2.63512) 2160(0.477957) 0(0.0754361) 300(0.0068697) 607055099444498921847583147982450809557514004451282871917948174791099265283291964431544302627498111551020109672026017537034605137651109768044489243175210279 ... [/CODE][/QUOTE] Not sure that I can give entirely satisfactory reasons, but the Opterons with first limit 110M (p55optimal) are running circles around the xp's and the P3's (and another 80some xeons that went idle), all with first limit 43M (p50optimal). Score: 5to2. My intended reason was that c155c169's tested to p50 were more likely to factor than the c234c299 (as well as some time in c3xx), even though the latter were only tested to p45. With explanation that too many of the c234c366's with factors under p45 removed had (on average) few factors in ecm range (like lots with smallest factor above p100, say). The first step limits oughtn't to make that much difference, as the factors being found are well within range of the smaller limits, given a larger number of curves. I'm fairly certain that the xp's are spending considerably more "work units" (without actually checking how these are actually defined); and with the addition on the xeons there's now a fairly substantial effort on the c155c169's of difficulty under 220, that hasn't found anything at all (this year). Perhaps that's since smaller difficulty numbers had more ecm (from other users?), or the previous runs used smaller limits, so were less likely to miss p46p54 factors (smaller standard deviation?). Anyway, here's the new one, p53=84382257093351217403808536729720911956398743537658819 with snfs difficulty 262.24, way harder than the 156digit gnfs. Bruce 
New Cunningham C122 (from 6,365+ after p60)
[QUOTE=garo;48287][code]Base Index Size 11M(45digits) 43M(50digits) 110M(55digits) 260M(60digits) Decimal
... 6 365+ C182 0(2.09174) 1500(0.38003) 590(0.0622008) 0(0.00529647) 18277199064023868716464418337366764898392423901374182657841980711016975079192366008607903315073044637550970940888219527035615248207222941096199986090387235389044400550718035078208621 ... [/code][/QUOTE] Another Opteron factor from the c170c189's of difficulty 220 and up. One of the good points about this range is that any factor is likely to be useful. In this case, even the relatively low snfs difficulty 227 is wayharder than the cofactor: p60 = 254856004505238557834753259615355816338030694854500477132141 from c182, leaving a c122. I haven't heard yet from the usual suspects, but anyone considering polishing off the cofactor (please!) should make sure that they have a reservation with Sam before starting. Bruce PS  this was from the 2nd Opteron pass, which has since finished on the c182/c122. So it's at 1.66*t50, ready for gnfs (presumably). [2*t50, actually] 
Your p60 isn't prime,
54856004505238557834753259615355816338030694854500477132141 = 3 * 32827965463229429509624429 * 557004815164707788478198263318443 nor do any of the two larger prime factors divide a Cunningham number. Cutandpaste error? Alex 
[QUOTE=akruppa;98948]Your p60 isn't prime,
... Cutandpaste error? Alex[/QUOTE] Also only has 59digits; missing the leading 2. bd (fumblefingers) 
[QUOTE=bdodson;98947] ... leaving a c122.
I haven't heard yet from the usual suspects, but anyone considering polishing off the cofactor (please!) should make sure that they have a reservation with Sam before starting. Bruce [/QUOTE] Nevermind, Paul_Z is running it under ggnfs. Bruce 
c248 > c196, still snfs
[QUOTE=garo;48285][CODE]Base Index Size 11M(45digits) 43M(50digits) 110M(55digits) 260M(60digits) Decimal
... 6 347+ C248 0(0.267423) 0(0.0522979) 165(0.00921839) 0(0.00148122) 10964338925092426088126948470446380066426543127625758260950563307023836679285462922290667662199737110776460215222333365311710483202526721433806593060755250025989735671706430973854039253697040115169671969414787046146621487945446241359724861879837297 [/CODE][/QUOTE] 2nd p52 today (the other on the 2 discussion thread, this subforum), but at difficulty 270, the c196 cofactor isn't small enough (yet) for gnfs to be easier. p52 = 4254678785395250635090914262464410641424477007559249 Bruce (that's 6, 347+) 
[QUOTE=garo;48287][code]Base Index Size 11M(45digits) 43M(50digits) 110M(55digits) 260M(60digits) Decimal
... 6 371+ C243 0(0.267423) 0(0.0522979) 165(0.00921839) 0(0.00148122) 708166466456643165057206014273219061287362177418529773038894112079445263158180620536201218854777490094565472668909080513640035584576532631736455633532917590922654920000520013129647589582761390400628750882982003943873373104640036387930965924231 ... [/code][/QUOTE] No need for quibbling about this one, p52 = 2783700126792688988335822421768098189386895987206391 finishes 6,371+. Remarkably uniform these post t50 factors  the SilvermanWagstaff paragraph about reestimating the most likely factor size after a test finishes, which says that the likely size is just another few digits larger than the previous estimate seems to be well represented here. So best strategy after p50 is to look for p55; rather than deciding that most of the p5xs were already swept up, and jumping to p60. Not that I wouldn't be running B1 = 260M if our pcs had more RAM installed (as I'm doing with the Opterons), choosing optimal memory use rather than best strategy. Eight factors so far, a lateish p49 and an early p57, then five (!) p52's and a p53. Bruce 
[QUOTE=bdodson;111221]No need for quibbling about this one,
p52 = 2783700126792688988335822421768098189386895987206391 finishes 6,371+. ...[/QUOTE] This one also, p60 = 151634244917416206035101114864937647283016448179107389644473 finishing 6, 292+ One on Bob's remaining 768bit list of easier snfs numbers. (Sorry for a double report, not sure whether the nfsnet list wanted priority.) Bruce 
6,289+ has been done [page103 of Cunningham tables; Irvine gnfs]
6,283+ has been done [page104 of Cunningham tables; Leyland snfs] 6,353+ has been reduced to a c178 by Dodson [pages 98 and 101 of Cunningham tables] 6,358+ has been reduced to a c163 by Dodson [pages 91 and 101 of Cunningham tables] 6,365+ c122 has been done [Zimmermann, gnfs, page 104 of Cunningham tables] 6,369+ c178 has been done [Hoogendoorn, snfs, page 104 of Cunningham tables] 6,387+ c162 has just been done [Silverman, snfs, page 106 of Cunningham tables] 
6,762M = p78 . p82
1 Attachment(s)
The log is attached.
Because it was a quartic, the FB limits were lopsided and it worked out nicely. Interestingly, the sqrt was done modulo 53, because "no irreducible prime found, switching to small primes". Now, that was the last 6L/M number and the last one in all tables with difficulty under 200. There are some quartics left slightly above diff.200 (single "home"computer type projects). Serge 
That was 6,762M.

6, 304+ C216 = p78*p138
[QUOTE=bdodson;184267] ...an "appalling" collection of seven
new first holes set by Serge. Bruce [/QUOTE] (from over on the (nonsticky) 2+ discussion). Here's the first of the seven, 6, 304+ C216 = p78*p138, Batalov+Dodson snfs. A Most wanted number from page 106. The other early wanted numbers that are now first holes: [code] page 106: 3,509+ c171 B+D snfs 6,304+ c216 done 11,229 c217 Edwards 12,233 c215 251.45 0.855 (snfs difficulty, sb ratio) 12,232+ c181 250.37 0.723 page 107: 10,241+ c175 running [/code] Bruce 
[QUOTE=bdodson;185107](from over on the (nonsticky) 2+ discussion). Here's the first
of the seven, 6, 304+ C216 = p78*p138, Batalov+Dodson snfs. [/QUOTE] What are the factors? 
BTW:
what about a link in the first post like this: [url=http://factordb.com/search.php?query=6%5En%2B1&v=n&n=300&EC=1&E=1&Prp=1&C=1&CF=1&of=H&pp=100&se=Update]Fatoring Database Composites for 6+ beginning at n=300[/url] and if so, for the other subthreads, too. 
[QUOTE=kar_bon;185116]BTW:
what about a link in the first post like this: [url=http://factordb.com/search.php?query=6%5En%2B1&v=n&n=300&EC=1&E=1&Prp=1&C=1&CF=1&of=H&pp=100&se=Update]Fatoring Database Composites for 6+ beginning at n=300[/url] and if so, for the other subthreads, too.[/QUOTE] We already have a link, displayed with the main "Factoring Projects" entry for Cunningham Tables: [url]http://homes.cerias.purdue.edu/~ssw/cun/[/url] the link to "Page 112 (the latest page)" brings up [url]http://homes.cerias.purdue.edu/~ssw/cun/page112[/url] for which the current last entry [code] 5737 6, 304+ c216 693346929436160407667161921820423929978381970938958936441952882745560041213921. p138 Batalov+Dodson snfs [/code] shows the p78. Sam's label "5737" indicates that this is the 5737th factor in the Updates he maintains for the Cunningham tables. Under "old pages" one finds the first factor, from the first page, which appears to date from "August 1, 1981". Bruce 
[QUOTE=bdodson;185122]We already have a link, displayed with the main "Factoring Projects" entry for Cunningham Tables
(...) [/QUOTE] what i meant was a quick view of all composites of this table, with the ability to download/see the factors as text/short text/html on [b]one[/b] click! and the table in post #1 has not to be updated with C's and remaining composites (except the difficulties). the ECMefforts could also be stored at the numbers in the FactoringDatabase! 
[QUOTE=kar_bon;185128]what i meant was a quick view of all composites of this table, with the ability to download/see the factors as text/short text/html on [b]one[/b] click!
and the table in post #1 has not to be updated with C's and remaining composites (except the difficulties). the ECMefforts could also be stored at the numbers in the FactoringDatabase![/QUOTE] I was looking over post #1 in this subthread before the most recent factorization (already updated by Serge). There seem to be a lot (compared to the other 17 Cunningham lists?) of small numbers, six numbers under c180. Some snfs's; worst case gnfs's also in our current range. By contrast, the last 57 are above current msieve range. Might hope to drop one or two by ecm? On storing ECMefforts, you're aware that each of the post #1s were prepared by Garo (following earlier attempts from Bob and Rogue) at trying to record the Lehigh curve counts, c. summer 2005? It may be somewhat easier now, as the most recent cunningham.in from the ECMNET quick_start page is down to just 600 numbers. I've included a recent update among replies posted here, with counts corresponding to 7*t50, 4*t50, 3*t50, 2*t50 and 1.5*t50, depending upon size/digits (for all but the c190c233's, which were subdivided at snfs difficulty 250 (with 4*t50 below, 3*t50 above)). Almost all of these are either with B1 = 110e6 or B1 = 260e6, but translated into t50 = "tested to finding a given p50 to 62% probabilty", which might mean something like 3133 p55optimal curves, B1 = 110e6 and 1579 p60optimal curves, B1 = 260e6. (So these "t50" are the analog of pentium90 years, for ECMNET rather than GIMPS.) You'd need to have a very good reason for adding a fourth version of the Cunningham status (Sam's pages; PaulZ's ECMNET pages and these Garo/Rogue tables, as maintained by Alex and Serge). bd ps  In particular, Cunninghams have been removed from the Database ecm server, as having already been tested past the current target range there 
[quote=kar_bon;185128]what i meant was a quick view of all composites of this table, with the ability to download/see the factors as text/short text/html on [B]one[/B] click!
[/quote] I think that`s a very good reason. The Database is much more comfortable than the tables from Paul. Sure it`s a lot of work to update all Numbers in the Database  but if all the Numbers are in the Database it will save a lot of time and no factor will be overlooked/lost. IMHO its a logic consequence to use the Database. Regards Andi_HB 
[QUOTE=Andi_HB;185323] ...
The Database is much more comfortable than the tables from Paul. Sure it`s a lot of work to update all Numbers in the Database  but if all the Numbers are in the Database it will save a lot of time and no factor will be overlooked/lost. IMHO its a logic consequence to use the Database. Regards Andi_HB[/QUOTE] That would be my friend and coauthor Xilman? Those are "homogeneous" Cunninghams; they're different (and not in this thread). As noted in my reply that you skipped over in your followup to kar_bon's post, there's reason to be careful here, since my friend and (on a different project) coauthor PaulZ _does_ have a repository for Cunningham info. I'm also somewhat puzzled about your concern on having (Cunningham?) factors "overlooked/lost", as my first reply to kar_bon (the earlier post) carefully recorded that the current standard for "factoring databases" has been maintained since 1981. Can we agree to resume this discussion five years from now, to see which database has been more reliably maintained over time? I have no dispute with your logic in starting the mersenneforum factoring database. But when I click on the link in kar_bon's post, I find that the first entry has composite cofactor ... uhm, well, I see first digits; and then another click to get a formula for the cofactor. The main focus of the entry appears to be the known prime factors. But what I want to know about 6, 314+ is specific info on that remaining composite factor; the one we're giving our attention to in attempting to complete the factorization. I want to know whether it is a candidate for gnfs; or instead whether it's better by snfs. That would be the purpose of including snfs difficulty, recorded in the new format Batalov has been introducing in posts here in the "Cunningham Tables" forum. More specifically, I'm interested to know how the runtime for snfs compares with the runtime for gnfs; which is the purpose of the Serge ratio, which is now being included in some of the tables. Depending upon how that analysis turns out, I'm supposed to consider additional ecm efforts before starting sieving; or else declare that the cofactor is ready for sieving, and reserve further attention to the other composites in the tables. So again, you're more than welcome to include our factors in your database; not that you need an invitation. But I hope you'll observe that we have somewhat more specific data requirements than what you'd include in a general purpose database. I'm doing my best not to interpret your posts as suggesting that we'd be better off focussing on your interests, rather than the ones related specifically to factoring Cunningham numbers. I do know that there's a subthread on the forum factoring database. I'm even happy to have a pointer to how one accesses Cunningham numbers there. Perhaps with some further experience I might move consulting the database up from it's current standing as fourth among the four places one might consult for info on Cunningham numbers. At the moment, if I'm in need of the known prime factors of a Cunningham, I'm most likely to scroll down Sam's appendix A (the "main tables"). Takes more than one click, and some experience with the scrolling. Can't say for certain that I'd recommend anyone else to start there; but your reply doesn't make the correct comparison. Regards, Bruce PS  you did say "tables" in the reference to Paul(?). There's a "file" on Paul_Z's link "candidates"; namely c120355, but that seems unlikely to be what you meant. I can find prime factors there, but only because I have a copy of the (very) old appendix C used in ordering the entries. The ECMNET database I'm referring to applies only to ecm factors of Cunninghams, and is found on the quick_start page. It's also not the most likely place to look for prime factors, as it features the performance of gmpecm over time. Again, different specific info than what's in the forum database. PPS  perhaps I'm neglecting my main reason for prefering Sam's pages, Paul_Z's list(s) and the format here in the "Cunningham Tables" threads  the prime factors are attributed to the person that found/reported them, with a date and method used. Yet another special interest 
First sorry that i have mixed homogeneous Cunningham & Cunningham Numbers. :unsure:
Hmm maybe i was to fast with my answer and decision for the Database. I understand that for the Cunningham Numbers some more specific Informations are necessary like the ecm effort and the difference snfs/gnfs. The last month i have updatet a lot of numbers with different kinds and noticed that the Database is a good place to bring all the great projects sites under one hat. But i don`t mean the project sites are needless. Regards Andi_HB [SIZE=2][/SIZE] 
Well, just having a link to Markus' FactorDB will not hurt anyone, but let's not forget a simple fact that FactorDB was seeded with the Cunnigham tables (not any other way around). Both FactorDB and this thread messages are secondary and may at any time be terribly out of date to the real database of Prof.Wagstaff (and [URL="http://homes.cerias.purdue.edu/~ssw/cun/"]his pages[/URL]).
I'll try to make a simple oneliner to every header which will state the obvious and provide a link or two... 2+ and 2 pages have overlap with the GIMPS project's pages, and 10+ and 10, to the repunits (with many maintainers, for a list please see [URL="http://homepage2.nifty.com/m_kamada/math/10001.htm"]10001[/URL] and [URL="http://homepage2.nifty.com/m_kamada/math/11111.htm"]11111[/URL]). [COLOR=green]P.S. I put out [/COLOR][URL="http://mersenneforum.org/showthread.php?t=12278"][COLOR=green]a test for discussions[/COLOR][/URL][COLOR=green].[/COLOR] 
1 Attachment(s)
6,317+ has been completed by NFS@Home:
[CODE] 68digit prime factor: 11945361088850933777390788537647098376873971990473200125789018538899 158digit prime factor: 13346683767756739751221171391453612510290695982921903538908296073270577730965354291094433347373531609778283156038003000968646967209671655512834647619164750607 [/CODE] This one required 6 sqrt runs to find the factors. 
1 Attachment(s)
And 6,316+ has been completed by NFS@Home as well...
[CODE] 101digit prime factor: 20718198856970031943042431298278006707891007274509577088151415807574320198826712628040225780951132201 110digit prime factor: 12982820825896490041085564332226827434385115418527415362505503451547310539809374170981407741870653553618632449 [/CODE] 
[QUOTE=frmky;191961]And 6,316+ has been completed by NFS@Home as well...
... [/QUOTE] To complete the sequence of three Wanted from the 6+ list, we have 6, 314+ C209 factored as [code] prp69 factor: 127990570696623010387437346082972860280218929783270356827690059243181 prp141 factor: 188319680286819627530088258891375898122332689005870859461836523838286397646922041895253964126997311634948826781446996032824188043732759470097 [/code] Batalov+Dodson, snfs. Bruce 
1 Attachment(s)
NFS@Home has completed 6,334+. The postprocessing was completed with msieve. I ran the filtering, generated the matrix, and then transferred the matrix to Jeff Gilchrist. Jeff then completed the long linear algebra and transferred the dependencies back to me. I then ran the square roots. The log is attached.
80digit prime factor: 51502221799707178125025528282930027721442937798693063043926320591434734001630893 101digit prime factor: 41422280661767885986788301046332645192976796405559179732383361255631887230356707467626379138546914777 
Toss Up!
[QUOTE=frmky;198041]NFS@Home has completed 6,334+. The postprocessing was completed with msieve. I ran the filtering, generated the matrix, and then transferred the matrix to Jeff Gilchrist. Jeff then completed the long linear algebra and transferred the dependencies back to me. I then ran the square roots. The log is attached.
80digit prime factor: 51502221799707178125025528282930027721442937798693063043926320591434734001630893 101digit prime factor: 41422280661767885986788301046332645192976796405559179732383361255631887230356707467626379138546914777[/QUOTE] Bruce just found: 5799 6, 338+ c222 950762354554992360834931338167078172382237056559450288273. c165 Dodson ECMNET Whether to do this by SNFS (exponent divisible by 13) or GNFS is a tossup. Since the former requires no polynomial search, I would go with that. 
[QUOTE=R.D. Silverman;199627]Bruce just found:
5799 6, 338+ c222 950762354554992360834931338167078172382237056559450288273. c165 Dodson [B]ECMNET[/B] Whether to do this by SNFS (exponent divisible by 13) or GNFS is a tossup. Since the former requires no polynomial search, I would go with that.[/QUOTE]Well, if it's done by ECMNET, the factor was probably found by ECM. At 57 digits not at all that unreasonable. 
[QUOTE=smh;199684]Well, if it's done by ECMNET, the factor was probably found by ECM. At 57 digits not at all that unreasonable.[/QUOTE]
Silverman means that the [B]c165[/B] cofactor can either be done by SNFS or by GNFS (with almost equal difficulty). 
[QUOTE=smh;199684]Well, if it's done by ECMNET, the factor was probably found by ECM. At 57 digits not at all that unreasonable.[/QUOTE]
Hi; sorry for not providing the info here. As the ECMNET report lists B1 and sigma, the remaining question is the c165 cofactor, rather than the p57. This was found during pretesting for the next round of NFS@Home reservations. Sounds like Greg still plans snfs. Bruce 
[QUOTE=Andi47;199685]Silverman means that the [B]c165[/B] cofactor can either be done by SNFS or by GNFS (with almost equal difficulty).[/QUOTE]My bad. Should learn how to read more properly.

6,323+ has been completed up
[quote=frmky]
One last result for 2009! The composite cofactor of 6,323+ was the product of 106digit and 115digit prime numbers: 106digit prime factor: 8726220783196433420577926540172780111230892319895685342094694918556189538442501432986166567593663232876099 115digit prime factor: 1262399687013820450821465131661532266367566719536571507703805450077992967534028821105944824066406612254496684743187 The factors will be reported to the Cunningham project and will be recorded on Page 114. Let's have a productive new year! [/quote] at this following website [URL]http://escatter11.fullerton.edu/nfs/numbers.html[/URL] 
1 Attachment(s)
As Raman reports, 6,323+ finished a bit early and squeaked into 2009. It was originally due midDecember, but the linear algebra failed. A few relations were trimmed, and a new matrix was constructed and successfully solved. The log is attached.
In total, NFS@Home factored 22 Cunningham composites in its nearly four month existence, and has six more currently in linear algebra. I'm looking forward to what 2010 will bring! 
1 Attachment(s)
6,331+ is factored. As a test, it was completed with 32bit large primes. The size of the matrix generated was about the same size as would have been generated with 31bit LPs, demonstrating that the matrix size does not strongly depend of the large prime bound. The log is attached.
68digit prime factor: 10001312033685801300032151531732232582514112692078389782701922973061 160digit prime factor: 65895276032273530263048875365535917359061535246511133624566186538715266554188340585/ 77770302531875655837482720443630406486478245944869941397820842114167390421773 
[quote=frmky;201207]6,331+ is factored. As a test, it was completed with 32bit large primes. The size of the matrix generated was about the same size as would have been generated with 31bit LPs, demonstrating that the matrix size does not strongly depend of the large prime bound. The log is attached.
68digit prime factor: 10001312033685801300032151531732232582514112692078389782701922973061 160digit prime factor: 65895276032273530263048875365535917359061535246511133624566186538715266554188340585/ 77770302531875655837482720443630406486478245944869941397820842114167390421773[/quote] I've reported this factor to the FactorDB since it wasn't there already. Hope you don't mind...I didn't exactly count on it slapping my name on there like that. :ermm: 
1 Attachment(s)
Not a problem. I usually add them, but yesterday was a crazy day and I didn't get to it. :smile:
6,332+ is now also factored by SNFS. This one was routine. The log it attached. 69digit prime factor: 650106680542055228216904187084969212101711180529566573956155238949369 108digit prime factor: 437044495846780459786775320213708755010180640454196959129029284718895597993040438934936850297533075756275529 
1 Attachment(s)
NFS@Home has completed 6,338+. Another routine SNFS following Bruce's ECM find, but a nice split. The cofactor was definitely out of reach of ECM.
prp82 factor: 7374816340411679132081492812954747890931208487192188857067501570272900803526414417 prp83 factor: 19672458683457789288278992418450933122786990415625278087649712338543546066768023737 
[quote=frmky;204595]NFS@Home has completed 6,338+. Another routine SNFS following Bruce's ECM find, but a nice split. [/quote]
Here's a nonroutine p62, to finish 6,344+ C190 [code] 44098070546316336069732891124299479167253575131341897248372433 [/code] a first hole, #5 on the most wanted list. Nearly the last number from c190c209 to finish t55 ("second smallest 100 Cunninghams", now at either 7t50 or 6t50). I've started on c210c233. Bruce ____ [COLOR=green]ECM is not dead!! Long live ECM! :) Congratulations on a nice factor! SB. [/COLOR] 
[QUOTE=bdodson;205160]Here's a nonroutine p62, to finish 6,344+ C190
[/QUOTE] Excellent! Finds like this make up for the long stretchs of factorless ECM runs. 
6,355+
1 Attachment(s)
<snip>
that snip means what actually? 
[QUOTE=Raman;209932]<snip>
that snip means what actually?[/QUOTE] c211=p60*p61*p91 double ecm miss? 
[quote=R. Gerbicz;209937]c211=p60*p61*p91
double ecm miss?[/quote] These days can we consider up the factors within the "low sixties" digit range as ECM misses? 6,355+ is easier by SNFS rather If one has to find out a p60 factor by using ECM, then it should be a champion within the top 50 ECM factors table? So, people have to run up with ECM upon all numbers till they find out the factors? One cannot guarantee before itself that all the factors of the number are within the ECM range only This is in my perspective. I always favour SNFS rather than ECM. SNFS does guarantee the factors. That is why I don't actually prefer running up all those ECM curves. 
[QUOTE=Raman;209939]These days can we consider up the factors within the "low sixties" digit range as ECM misses?
[/QUOTE] No way, Jose. 
[quote=R.D. Silverman;209951]No way, Jose.[/quote]I'd allow exceptions for irony or for outright teasing.
Paul 
[QUOTE=xilman;209987]I'd allow exceptions for irony or for outright teasing.
Paul[/QUOTE] I employ a conversion formula: Tragedy is me pulling a P63 factor on an SNFS150 job. Comedy is you pulling a P53 on the same job. Since the first one happened to me, it's an ECM miss. 
[url="http://mersenneforum.org/showpost.php?p=106715&postcount=11"]Bruce explained it all[/url]

Postfactum it is fairly easy to run a single "ecm v v 11e7" curve on one's own hardware and estimate if the factor had a 50/50 chance to have been found in 1/10th of the total time spent on NFS factoring. If it had not, sleep well and give an understanding chuckle to those who would invariably call your factor an ECM miss.
Because they will, no matter what... :jokedrum: 
[quote=R. Gerbicz;209937]c211=p60*p61*p91
double ecm miss?[/quote] 6,355+ c211 = p60*p61*p91 In any case, if you assume that this is an ECM miss Think of 6,365+ c182. Remember that one? That case 6,365+ c182 split up into as p60*p61*p62 That p60 was an ECM hit! Mr. Paul Zimmermann did the remaining c122 of 6,365+ by using GNFS. And then why is there such a similarity between 6,355+ with 6,365+ :rolleyes: Which state are you people from? Is this information right then? Mr. Batalov, frmky > California Dr. Silverman > Massachusetts (?) jasonp > Maryland bdodson, Xyzzy > Pennsylvania, where this mersenneforum server is being hosted up Prof. Wagstaff > Indiana Prime95 (aka George Woltman) > Florida philmoore > Oregon jbristow > Washington 
1 Attachment(s)
Non sequitur?
[URL="http://en.wikipedia.org/wiki/Phil_Moore"]Phil_Moore[/URL] is from Maryland. 32.893,117.2535 is definitely in California. You betcha. P.S. Gotta love the new smilies. :tantrum: [ATTACH]4946[/ATTACH] Happy April's whatever! 
[QUOTE=Raman;210274]6,355+ c211 = p60*p61*p91
In any case, if you assume that this is an ECM miss ...[/QUOTE] This number was perhaps somewhat undertested by ecm. Only 4t50, fewer curves than needed to find a p55 factor. A full ecm pretest, relative to the sieving difficulty, still would not have been sufficient to find a p60, or even two. bd 
6,368+
I have brought shame upon my family through the 11th generation: the C171 was a P61.P111.
[code]P61= 3892757110616175619125134299275807031820501573185619194311329[/code] Thanks to jrk for the polynomial. (I shall now absent myself from the presence of more worthy people.)d 
6,353+
This C178 GNFS ran a little faster thanks to jrk's suggestion that we try triple large primes on the algebraic side:
n: [CODE]3495720155744160390308702080911694892393254003819177989194364433392602119210358965833430295064663146579080152295928278131537398607330890608815038143831212204077824454760817944697 # norm 1.828473e17 alpha 7.945069 e 9.914e14 skew: 5242872.26 c0: 1415684462271305089012313057623015234842880 c1: 56489085491552175398550702459917716 c2: 355405802142076475701272154680 c3: 30573939026244353965597 c4: 18914955682611026 c5: 637985160 Y0: 5594293033634964367018772799829077 Y1: 10914669743009582011 rlim: 60000000 alim: 60000000 lpbr: 31 lpba: 31 mfbr: 62 mfba: 90 rlambda: 2.6 alambda: 3.6[/CODE] This seems to buy around an 8% improvement in speed for GNFS jobs of this magnitude. The individual Q values require more time, but we generate more relations per Q. The C178 split as P68.P110: [CODE]P68: 76772819749620922859599019064869997729081875556728878881833848945739 P110: 45533304197302470775235834478317413598842411794792485571017691246712640554863455599919842904873592456844389323[/CODE] 
That's a very neat trick. Congratulations!

1 Attachment(s)
NFS@Home has finished 6,346+. A standard, runofthemill SNFS. The log is attached.
[CODE]prp95 factor: 56164757259658694865317697513568456493084555649771650505190443472644658585771052699471490056581 prp147 factor: 11960561240826642457187862060325535944398686262517008326251321014 2881955861855697561030442897124917553684448866765015014996075103318345732384959573 [/CODE] 
1 Attachment(s)
NFS@Home has finished 6,379+ by SNFS. This is a secondplace Cunningham project champion for SNFS difficulty. Perhaps a little more ECM was in order. :smile: 690M unique relations produced a 36.3M matrix. The complete log is attached.
[CODE]prp62 factor: 39594233382490829759605818014230525162442624379592766682403039 prp208 factor: 4820647143682973621292002958588937598451150284915247942312749863705514560478233011200820934852999072676798890436532716898257110294756505772592641375094560163124805206507825142957485484934879455289116453808211 [/CODE] 
[QUOTE=frmky;239530]NFS@Home has finished 6,379+ by SNFS. Perhaps a little more ECM was in order.[/QUOTE]
I concur. Perhaps we can cajole EPFL to running presieving ECM trials on NFS@Home candidates?????? Just an idea......:smile: I'd like to cajole them into running ECM trials on the 2+ tables as well as the 2. They are doing such a terrific job with the latter. :bow: I'm sure they could save a lot of NFS time by picking off some of these numbers. 
[QUOTE=frmky;239530]This is a secondplace Cunningham project champion for SNFS difficulty.[/QUOTE]
Isn't it third (2,1039 is 1st, 2,1183 is 2nd)? 
[QUOTE=10metreh;239668]Isn't it third (2,1039 is 1st, 2,1183 is 2nd)?[/QUOTE]
Yes, it is. So many records are falling lately I can't keep track! :smile: 
... when to quit ...
[QUOTE=frmky;239530]NFS@Home has finished 6,379+ by SNFS. This is a secondplace Cunningham project champion for SNFS difficulty. Perhaps a little more ECM was in order. :smile:
[CODE]prp62 factor * prp208 factor [/CODE][/QUOTE] Despite much reduced resources, the Lehigh pretest on this number was 23827 new curves (B1 = 260M, B2 = gmpecm default) upon it's selection as a NFS@Home candidate; following an initial test of 1.5t50, so c. 2400 additional curves. Past 3t55, but short of c. 5t55 = c. t60. The current test of a new windows7 image is showing 100 cores by day, 600 cores overnight (core 2 duos). That's still below the c. 1200 cores with the old xp image, but these may be faster, with more memory. But a lot better than none during the c. six months (I forget how long it's been) while the windows people had excluded condor/ecm. On purpose. The daytime test is very good to see, if it passes; the first yearorso was 24/7, which was dropped to 12/7 on widespread belief that there was serious interference  especially condor being slow to exit, while people were trying to get inclass presentations to open. Very not good. Even if/when enhanced resources are up and stable (they're being very thorough about testing; which is good), I don't see tests past 2t55 as good use of the University's resources. Nearterm large distributed 16e projects are a worthwhile exception, but 60% of t60 (= c. 3t55) is about as far as I'd like to go (that's perhaps t57.5? no promises here about p59andup). I also find it hard to believe that a boinc project for testing past 2t55 (that is, after 2t55 has failed, running towards t60) would be attractive. Just too few factors in [2t55, t60], unless one has a very large pool of very patient users. Besides, GPU projects get far better credit/price than any CPU app. Bruce (Looks like GPUgrid runs on our linux/tessla 20's (c2050), so perhaps I'll see for myself.) 
1 Attachment(s)
Catching up here, NFS@Home finish 6,347+ a week or so ago.
[CODE]prp95 factor: 70511507899987042021399421608627600087695968291036987926849957371379710825930676085846246065057 prp101 factor: 36547331438884099727114410025437724191882639263092614191503321841305380338823023355542833953649420929 [/CODE] 
1 Attachment(s)
And 6,374+ is now done.
[CODE]Mon May 23 15:13:40 2011 prp104 factor: 16662090550947267817532833084936567469376561931117199336634319011364776739722634584799904405393505087889 Mon May 23 15:13:40 2011 prp111 factor: 551199432504034094014614942720208216988359859314312573575833568466762683056295417002390729187861797699416750129 [/CODE] 
A large (p65!) ECM factor was uneventfully posted in the [URL="http://homes.cerias.purdue.edu/~ssw/cun/xtend/up6p"]extensions[/URL]:
[CODE]6, 822L c172 57670113141808252240352311142780968492223118520622897175521034757. p107 Wagstaff ECMNET[/CODE] 
[QUOTE=Batalov;282829]A large (p65!) ECM factor was uneventfully posted in the [URL="http://homes.cerias.purdue.edu/~ssw/cun/xtend/up6p"]extensions[/URL]:
[CODE]6, 822L c172 57670113141808252240352311142780968492223118520622897175521034757. p107 Wagstaff ECMNET[/CODE][/QUOTE] Sam bumped his p63 off of the top10, leaving the 10th a p64, one digit better than the 10th of 2010. Not much time for another top10 factor this year! Bruce 
6+,6LM tables were officially extended. (from 451 to 500, LM to 1000)
There may be some projects accessible to homestyle enthusiasts, e.g. 6,456+. 
Here's the 6,490+ log.
[PASTEBIN]EnR8dw6p[/PASTEBIN] 
6,376+ is done.
[PASTEBIN]DUiuCNaF[/PASTEBIN] 
A nice split for 6,460+!
[PASTEBIN]jHfbAmf3[/PASTEBIN] 
[QUOTE=frmky;446481]A nice split for 6,460+![/QUOTE]
Brilliant! 
[QUOTE=xilman;446586]Brilliant![/QUOTE]
Pun intended I'm sure! 
[QUOTE=frmky;446637]Pun intended I'm sure![/QUOTE]Sometimes I'm too obvious.

6, 389+ c242 17773009901252360471924269249318148260447935679384645157188770608035885899698538249694861593754194361. p142 NFS@Home snfs
[url]http://pastebin.com/6N2HjzTB[/url] 
6,394+ done by NFS@Home

6, 404+ c266 17779141835970240570705720301077355646755619077045499858214084160627856057. p193 NFS@Home snfs

6,442+ Done by NFS@Home

All times are UTC. The time now is 15:45. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2021, Jelsoft Enterprises Ltd.