Have a look at the partition numbers
 

If you want the opportunity of running ECM 24/7 and getting a freshly-baked factor per CPU in your inbox most mornings, can I commend to you the partition numbers from

[url]http://www.asahi-net.or.jp/~KC2H-MSM/mathland/part/[/url]

I am currently clearing up the 13000-13500 range and running ECM on the 20000-21000 range, but in other ranges there are literally thousands of numbers as small as C101 that have seen only ECM with B1=50k, and others that have been well-ECMed and are just sitting there begging to be GNFSed. Come on in, fill your boots!

There *are* interesting divisibility properties to be found among the partition numbers: the famous 5|p(5n+4), 7|p(7n+5), 11|p(11n+6), and infinitely many (see [url]http://www.sciencenews.org/articles/20050618/bob9.asp[/url] ) weirder ones (for example, part(17303n+237) is divisible by 13), but I'm fairly sure they don't apply for factors this big; on the other hand, there being no strong mathematical use for the factors is scarcely a disincentive for other factorisation projects.

Trying to sound like an advocate for the Oregon Trail,

Tom

[QUOTE=fivemack;106323]If you want the opportunity of running ECM 24/7 and getting a freshly-baked factor per CPU in your inbox most mornings, can I commend to you the partition numbers from

[url]http://www.asahi-net.or.jp/~KC2H-MSM/mathland/part/[/url]

I am currently clearing up the 13000-13500 range and running ECM on the 20000-21000 range, but in other ranges there are literally thousands of numbers as small as C100 that have seen only ECM with B1=50k, and even some small enough that QS is the right method. Come on in, fill your boots!

There *are* interesting divisibility properties to be found among the partition numbers: the famous 5|p(5n+4), 7|p(7n+5), 11|p(11n+6), and infinitely many (see [url]http://www.sciencenews.org/articles/20050618/bob9.asp[/url] ) weirder ones (for example, part(17303n+237) is divisible by 13), but I'm fairly sure they don't apply for factors this big; on the other hand, there being no strong mathematical use for the factors is scarcely a disincentive for other factorisation projects.

Trying to sound like an advocate for the Oregon Trail,

Tom[/QUOTE]

You should be aware that the partition numbers were part of the RSA
Challenge contest back in the 90's. They were restricted to those
with prime indices, but a VERY LARGE NUMBER of them were fully factored.
Check the RSA website to see if the data is still available.

I will check to see if I still have a copy of the data.

Bob

[QUOTE=R.D. Silverman;106326]You should be aware that the partition numbers were part of the RSA
Challenge contest back in the 90's. They were restricted to those
with prime indices, but a VERY LARGE NUMBER of them were fully factored.
Check the RSA website to see if the data is still available.

I will check to see if I still have a copy of the data.

Bob[/QUOTE]

That data has already been merged into Mishima's tables; at least, I looked at [url]http://www.ontko.com/~rayo/primes/[/url] to get the RSA-challenge data, then grepped the Mishima tables for some of the largish factors from [url]http://www.ontko.com/~rayo/primes/hr_p135.txt[/url] and found them all.

[QUOTE=fivemack;106330]That data has already been merged into Mishima's tables; at least, I looked at [url]http://www.ontko.com/~rayo/primes/[/url] to get the RSA-challenge data, then grepped the Mishima tables for some of the largish factors from [url]http://www.ontko.com/~rayo/primes/hr_p135.txt[/url] and found them all.[/QUOTE]

That is good news. I am glad that the data did not get lost.

Reserving 14984 c104 for msieve (QS)

[QUOTE=Andi47;106336]Reserving 14984 c104 for msieve (QS)[/QUOTE]

Should we tell Mishima about our reservation? :ermm:

Luigi

I don't think there are all that many people working on these numbers ... contributions this year have, with one exception, been by me or by Hisanori Mishima himself, which is really why I posted here to drum up more interest. It would be nice to tell him about the reservations, but he manages the site manually so we don't want to overload him entirely.

Out of curiosity, I collected all the cofactors together, and did 35 rounds of GCD(product of half the cofactors selected at random, product of the other half), all of which returned 1. So I think it's quite unlikely (IE there are about 2^24 pairs, and for any pair the probability is 2^-34 that both were on the same side all 35 times) that any number will divide more than one of the cofactors.

Reserving 29328 c101 and 28819 c102 (as an attempt to compare msieve's QS and GNFS with numbers in similar size)

[QUOTE=fivemack;106340]I don't think there are all that many people working on these numbers ... contributions this year have, with one exception, been by me or by Hisanori Mishima himself, which is really why I posted here to drum up more interest. It would be nice to tell him about the reservations, but he manages the site manually so we don't want to overload him entirely.[/QUOTE]I've done quite a few last year before cleaning up the small composites on the cyclotomic tables. Most < 110 digits are done now (I did 7-800 between 100 and 110 digits in the last few months) so i might return to the partition tables. Most composites above 20K haven't had enough ecm though. Last time i found quite a few factors with GNFS in the 30 digit range.

I also has been a long time i did any numbers of the (Generalized) Cullen and Woodall numbers so i might return there first.

[QUOTE=R.D. Silverman;106326]You should be aware that the partition numbers were part of the RSA
Challenge contest back in the 90's. They were restricted to those
with prime indices, but a VERY LARGE NUMBER of them were fully factored.
Check the RSA website to see if the data is still available.

I will check to see if I still have a copy of the data.

Bob[/QUOTE]

As I recall, Paul Zimmermann and Arjen are still waiting for the
last quarter's prize. We quit when the prizes were no longer
being given. But my recollection is that there was another round
of factors waiting for the quarter to finish (to be eligible for the next
quarter's prize), and that some of the later ones that we did
submit never got included.

I can check, but it has been quite some time. Again, we were only
doing the ones of prime index (the thought being that there were
too many of each given size, otherwise). Also, aside from the wish
that there might be instances of new congruences/divisibilities found,
these are (iirc) only gnfs candidates, with no chance of snfs --- that
was one of the appeals, in our case. Most of our early gnfs trials were
taken from the partition list, the first ones for gnfs above c110,
including c112, c119, c116 from our Crypto'95 paper on the cycle explosion
(gnfs with four large primes). -Bruce

PS -- sentance fragment patched. There are also some of our
factors on one of Brent's early pages, from back when he was taking all
ecm factors above p40 (especially the year or two when we were
working toward p50, finished with Curry's p53).

Reserving 14735 c104 (GNFS)

[QUOTE=smh;106415]Reserving 14735 c104 (GNFS)[/QUOTE][CODE]N=12332341160200760366847722782949606825270758700381531837597837316250818326317511743110920063409242258717 ( 104 digits)
Divisors found:
r1=1485143488073298293923414948921496082307837993 (pp46)
r2=8303804487066576064650357194157798232044951246095567680469 (pp58)
Total time: 7.88 hours.[/CODE]

[QUOTE=bdodson;106361]As I recall, Paul Zimmermann and Arjen are still waiting for the
last quarter's prize. We quit when the prizes were no longer
being given. But my recollection is that there was another round
of factors waiting for the quarter to finish (to be eligible for the next
quarter's prize), and that some of the later ones that we did
submit never got included.
[/QUOTE]

I was handling the verification of results and saw to it that the
marketing people mailed out the prizes.

Then I got laid off. My guess is that noone else took over and that
it fell through the cracks.......

[QUOTE=Andi47;106350]Reserving 28819 c102[/QUOTE]

Fri May 18 20:35:28 2007 prp46 factor: 2896980316642729353055002268196586942743872217
Fri May 18 20:35:28 2007 prp56 factor: 76503441441413011494575167031398404085894766827617190241

approx. 17 cpu-hours with msieve (QS)


Edit: Reserving 29130 c103

Can I just check that people who find factors are sending them to [email]kc2h-msm@asahi-net.or.jp[/email] directly, as well as posting them here?

[QUOTE=fivemack;106499]Can I just check that people who find factors are sending them to [email]kc2h-msm@asahi-net.or.jp[/email] directly, as well as posting them here?[/QUOTE]Not yet, but i will.

I would also like to reserve [COLOR="Black"][B][U]ALL[/U][/B][/COLOR] remaining (the ones not reserved in this thread) 103 and 104 digit composites.

[QUOTE=R.D. Silverman;106487]I was handling the verification of results and saw to it that the
marketing people mailed out the prizes.

Then I got laid off. My guess is that noone else took over and that
it fell through the cracks.......[/QUOTE]Somewhere I still have a record of the partition factors from that computation.

I made a few hundred bucks over the course of several years. Not a way to get rich, especially not if the proceeds are donated to charity.

Eventually, I got tired of the gamesmanship implicit in the structure of the challenge.

Paul

[QUOTE=Andi47;106336]Reserving 14984 c104 for msieve (QS)[/QUOTE]

Sun May 20 18:37:19 2007 prp45 factor: 118510482144290848347459027738323943707271259
Sun May 20 18:37:19 2007 prp60 factor: 102892983755174194924983528561338993128741779676166226537677

[QUOTE=fivemack;106330]That data has already been merged into Mishima's tables; at least, I looked at [url]http://www.ontko.com/~rayo/primes/[/url] to get the RSA-challenge data, then grepped the Mishima tables for some of the largish factors from [url]http://www.ontko.com/~rayo/primes/hr_p135.txt[/url] and found them all.[/QUOTE]

Not exactly. Ray Ontko's web page has "honor rolls" up to 165-169 digits;
but our factors went past that --- without looking too closely, I see
one at 181-digits

[QUOTE]
p(27767)=2222164031682059894256456152196952624981714302844666210807\
1623414759364252901862750351685028160708519432209308498756197660187\
55775489619728333950278651217220247620722925992858424104 (181 digits)
Factors: 2 * 2 * 2 * 3 * 7 * 7 * 143982495659 * 911432531209 * 275433214610326301 * 292795868758239438861071867242457 * 1785473110332531860394372415833097856861274839468200152025175114737\
01604587588088467419299970751228925337
Date: March 14, 2000
Method: trial division, ecm (p33, found December 1999)
Name: Bruce Dodson, Arjen K. Lenstra, Paul Zimmermann
[/QUOTE]

Anyone have 170-174, 175-179 and maybe 180-? The contest
only covered maybe 40-digits? It's been a long time. 10-digits for
8-point numbers, 10-digits for 4-points, 10-digits for 2-points and
20-digits for "1-pointers"? For example, iirc, p(11087) was the smallest
unfactored prime index partition number when we factored it, and it
had 113-digits. That meant 113-digit to 122-digit partition numbers
of prime index were worth 8-points each, then 123- to 132-digits
4-points, 133- for 2-pts, then 143- to 162-digit numbers were worth
1-point. Nothing for larger numbers. So when Arjen sent in the factorization,
on the last day of that quarter's challenge, December 31, 1993 in this
case, that meant that there was a new smallest unfactored size ---
for eg, the 2nd largest unfactored might have been 115-digits, which
opened up two new digits 163- and 164-digits --- worth 0-points on
Dec 31, but 1-point on Jan 1st (point ranges only changing on the
Quarters). We knew that, but no one else did, and prepared easy new
1-point numbers before the end of the quarter (while they were worth 0),
and sent them in on Jan 1 (when they were worth 1-point). As you
can see, xilman's still annoyed; but Arjen took a large amount of pleasure
winning most Quarters. Someone at RSA Data's idea, not our fault. Really.
There was a Quarter when someone anticipated this, and sent in previous
0-point numbers, when we hadn't factored the smallest number, so the
effort was wasted, as they were still worth 0-points. Peter was a fan of
sending in new numbers before Arjen got to them; well ...

Ah, perhaps it's comming back to me, there may not have been an
honor roll for 180-digits? We'd factored enough smallest index numbers
so that 181-digit was supposed to count (RSADSI's rules), but I don't
recall whether we ran out of honor rolls, there at the end. But there
were honor rolls of 170-174 and for 175-179, which aren't on Ontko's
page --- looks like I ought to be able to dig out our reports from
170-181 digits, but the Honor rolls would have other ones aside from
the ones that we found -- it would be better if someone has them. -Bruce

PS -- Ah, that p33 in the RSA-report above is already listed; probably
most of the other easy ones as well. Oh. But Tom's right about the
conguences; looks like the theory's set now (although it wasn't when
Hendrik suggested partition numbers as challenge numbers). Seems that
Ono only gave one new example; then assigned the question for under-
grad research --- Weaver got 76065 new congruences, but the largest
prime divisor was 31 --- using modular forms of level 576. If we wanted
10-digit prime factors of partition numbers, the level would likely be hugh,
computing coef impossible, and the congurences wouldn't start until (very)
large index. I don't see 17303n+237 on her list though, is this more
recent? Lastly, my Mother's side of the family is quite proud of being
descended from someone that went west on the original 'Trail, some five
generations ago. Ought to be irrelevant, but UofO's office of financial
aid was quite annoyed to find someone that actually met the conditions
set by one of their donors; got me through the first two years of college.

[QUOTE=smh;106507]I would also like to reserve [COLOR="Black"][B][U]ALL[/U][/B][/COLOR] remaining (the ones not reserved in this thread) 103 and 104 digit composites.[/QUOTE]Done. I'll send them later.

I'll continue with the 105 digit composites.

[QUOTE=smh;106696]Done. I'll send them later.

I'll continue with the 105 digit composites.[/QUOTE]

That's quite impressive: 45 factorisations of about eight hours each in three days, so at least five full-time CPUs. Do you have a patch for the "lambda-comp" bug during polynomial selection that has thwarted my attempts at running completely automated ggnfs?

I suppose that with that level of automation there's little point in even running ECM first; I'm finding that about one in ten of the 20000..21000 cofactors produces a factor after 150 curves at 3e6, fairly independent of cofactor size, which means I get factors at about the same rate as if I were NFSing starting at the smallest ones. Mostly I'm NFSing the C100..120 numbers that appear when you break off a P3x from a composite (and MPQSing the occasional C8x, but that takes less than an hour); that's enough to fill up my compute resources nicely ... I still sometimes get an NFS factor smaller than the ECM factor.

[QUOTE=fivemack;106699]That's quite impressive: 45 factorisations of about eight hours each in three days, so at least five full-time CPUs. Do you have a patch for the "lambda-comp" bug during polynomial selection that has thwarted my attempts at running completely automated ggnfs?[/QUOTE]The c104's actually take a bit longer on the servers i'm running them (some are dual cpu). The 8 hours is alos exluding poly search as that is not recorded in the log file.

I don't know what you mean with a "lambda-comp" patch. I'm just creating a batchfile where i call factlat.pl with the relevant .n file.

In between factorizations i run a cleanup script to remove all files exept the results file.

It's really fire and forget. ATM i don't have time to create poly's etc, thats why i'm running these numbers. It's just copy/past from a file i grep from the website

Ah. I find that about one factlat.pl run in three terminates half-way through polynomial selection with a message 'lambda-comp' from pol51opt.

This isn't a problem if your batchfile notices that the run has failed and launches it again - it's generally found a half-decent polynomial by that point and just carries on using that one - but that makes the run-script a little harder to write. It's a little more annoying if you launch four jobs manually, go to bed, and find that two CPUs have idled overnight.

[QUOTE=fivemack;106705]Ah. I find that about one factlat.pl run in three terminates half-way through polynomial selection with a message 'lambda-comp' from pol51opt.

This isn't a problem if your batchfile notices that the run has failed and launches it again - it's generally found a half-decent polynomial by that point and just carries on using that one - but that makes the run-script a little harder to write. It's a little more annoying if you launch four jobs manually, go to bed, and find that two CPUs have idled overnight.[/QUOTE]I can't find it in my own script (are you using the latest from sourceforge?) but i remember long time ago, commenting out one or two lines in the script (think a line with 'die')

My batch file looks something like:

factlat.pl 1
call cleanup.bat
factlat.pl 2
call cleanup.bat
....

Where i put the numbers in 1.n, 2.n, etc

For composites below 110 digits i don't treally care if the poly is optimal or not. An hour more or less is not worth the time babysitting my computers.

[QUOTE=smh;106696]I'll continue with the 105 digit composites.[/QUOTE]Done.

I'll continue with the 106 digit composites.

Is anyone working on the smallest composites (101 and 102 digits)?
Although GNFS might be faster, they are nice candidates for msieve.

reserving 28314 c101 for GNFS

[QUOTE=Andi47;106350]Reserving 29328 c101[/QUOTE]

Tue May 29 11:42:42 2007 prp49 factor: 3519998070322949609923151104348917738657885664351
Tue May 29 11:42:42 2007 prp53 factor: 17003238992013333150854317713525675502414489255329857


[QUOTE=Andi47;106490]
Edit: Reserving 29130 c103[/QUOTE]

Mon May 28 05:40:56 2007 prp46 factor: 7701007183832465344772923932080967488831333947
Mon May 28 05:40:56 2007 prp57 factor: 572015095894199635535366612427087111835980569963266301783

Reserving 20647 c101 and 20891 c102

[QUOTE=Andi47;107329]Reserving 20647 c101 and 20891 c102[/QUOTE]

20647 c101:
Thu May 31 08:56:49 2007 prp36 factor: 552308749347187909031142322734203299
Thu May 31 08:56:49 2007 prp65 factor: 24927766151680063520982636974281103909592483730458610592774550481


20891 c102:
Thu May 31 11:24:36 2007 prp48 factor: 348576993433347561253167275618901474537488577701
Thu May 31 11:24:36 2007 prp55 factor: 1110662031911332571745059263860379031583132441968015533

[QUOTE=smh;106924]I'll continue with the 106 digit composites.[/QUOTE]Done, including the first 4 c107's.

[quote=nuggetprime;107196]reserving 28314 c101 for GNFS[/quote]
I didn't factor this one with gnfs because I didn't know how to use ggnfs. but now I know and with my next reservation, 29328, I will try to factor, with factLat.pl, my first number using gnfs.

Factors of 28314:
[code]
p47 factor: 11293260017991808632377462474444514902170890901
p55 factor: 6800209839747876175751542155675097921696821774445715093[/code]
(factored with msieve/QS)

nuggetprime

Andi,

Did you report the factors you found?

All numbers for which you showed factors are still marked composite on the site.

[QUOTE=smh;107538]Andi,

Did you report the factors you found?

All numbers for which you showed factors are still marked composite on the site.[/QUOTE]

No, I only reported them here in this thread.

[QUOTE=Andi47;107542]No, I only reported them here in this thread.[/QUOTE]
See [url]http://www.mersenneforum.org/showpost.php?p=106499&postcount=16[/url]

[QUOTE=smh;107543]See [url]http://www.mersenneforum.org/showpost.php?p=106499&postcount=16[/url][/QUOTE]

Thanks, Mail is out.

29328 successfully factored with ggnfs. Will mail the factors to Mr.Mishima tomorrow. Now trying 15326 c114 for a bigger number.

nuggetprime

reserving 13603 c114

[QUOTE=smh;107412]Done, including the first 4 c107's.[/QUOTE]

Are you continuing with larger numbers, or have you found another application for your demonstrably-enormous compute farm?

[QUOTE=fivemack;108276]Are you continuing with larger numbers, or have you found another application for your demonstrably-enormous compute farm?[/QUOTE]It's just 4 dual cpu servers which are also used for other things.

I haven't had the time to load another batch of numbers. I'll try to load them this weekend. I'll post a reservation.

I'll reserve all c107.

i'll try 14013 c109.

[QUOTE=smh;108373]I'll reserve all c107.[/QUOTE]They're done and were sent last weekend.

approximately how long would a c109 take using msieve's nfs code? the polynomial selection was ran for about 45 minutes using ggnfs. this is on an athlon xp 2500+ (1.83Ghz)

[QUOTE=antiroach;109172]approximately how long would a c109 take using msieve's nfs code? the polynomial selection was ran for about 45 minutes using ggnfs. this is on an athlon xp 2500+ (1.83Ghz)[/QUOTE]
msieve's NFS postprocessing is ready for use, but the NFS sieving is much too slow, even with a good polynomial. You're better off using GGNFS for that. Using QS should take 6-7 days, using GGNFS for everything would probably take 2-3 days.

ah alright. thanks for the info.

Done 15326 c114. Tried everything with ggnfs, but then sqrt step failed. Dumped rels.bin files, "cat"ed, and runned msieve on them. This took about 1.5 hrs. Trying now 13507 c124.
Important: can anyone give me a script for merging the rels.dump files? procrels gave me 30 of them and entering every bash command is some work.

Thanks,
nuggetprime

[QUOTE=nuggetprime;109229]Done 15326 c114. Tried everything with ggnfs, but then sqrt step failed. Dumped rels.bin files, "cat"ed, and runned msieve on them. This took about 1.5 hrs. Trying now 13507 c124.
Important: can anyone give me a script for merging the rels.dump files? procrels gave me 30 of them and entering every bash command is some work.
[/QUOTE]

I'm not quite sure what you mean by 'a script'; what's wrong with 'cat ../spairs.* >> msieve.dat'? I attach the perl thing I use, syntax

[code]
perl make_msieve.pl <polynomial file that you fed to ggnfs> <long list of relations files>
[/code]

Can anyone please send/post the correct factlat.pl for GGNFS
version ggnfs-0.77.1-20060513?

This would be much appreciated!

Thank you

Partition #14013 - c109
n: 6287519180589851139882693558840635632241012858583497665823906751707884219221125879481642916986596731056494167

Fri Jun 29 22:26:50 2007 prp40 factor: 4055867462511507246809540765263688334409
Fri Jun 29 22:26:50 2007 prp70 factor: 1550227969406190201420489172994971768332681745493513321325967657909663


Reserving 14366 - c108

14366-c108 done

prp49 factor: 1180104789623098839323309856204121636411347151567
prp60 factor: 106918835010797637897677176686144644452187287325332530679607

I'll reserve 14520 - c108.

14520 - c108 done

prp46 factor: 5315801795562320384285260047752595470515521017
prp63 factor: 154229753842137920104342044001922615429670228584132076105452171

13603 - c114

prp54 factor: 242815511986682711062713330659399733165428299624594537
prp61 factor: 3796089811082851856236286208090794928780154124748456514983293

[QUOTE=Andi47;119648]13603 - c114

prp54 factor: 242815511986682711062713330659399733165428299624594537
prp61 factor: 3796089811082851856236286208090794928780154124748456514983293[/QUOTE]

From [url]http://www.asahi-net.or.jp/~KC2H-MSM/mathland/part/reserved.htm[/url]
[QUOTE](October 22, 2007)

Remaining 35 composites in the range 13501 to 14000
are reserved by Sean A. Irvine.[/QUOTE]I'm working on the range 14001 - 14500 and have a dozen or so results not yet on that page.

[QUOTE=smh;119657]From [url]http://www.asahi-net.or.jp/~KC2H-MSM/mathland/part/reserved.htm[/url]
I'm working on the range 14001 - 14500 and have a dozen or so results not yet on that page.[/QUOTE]

[QUOTE=Andi47;108248]
(June, 13, 2007)

reserving 13603 c114[/QUOTE]

Took me quite long, I know...

I'm about half way through the 35 numbers, and yes I had already finished p13603.

Sean.

Just finished the next block of numbers.

[CODE]p13504 Using B1=11000000, sigma=1496571855
269873106925030152845186709469315811424923 (p42) * P77

p13507 By GNFS, 2 days
107392182166303675577941384510775896635060095056039793 (p54) * P71

p13516 By GNFS, 1 day
20709693035616414820820511558553383063424894888811 (p50) * P72

p13530 By GNFS
501002126961488927359851463090811530300351590923750009099 (p57) * P68

p13541 By GNFS
70199825281859702395394532134026134872765844892182996187501 (p59) * P64

p13560 By GNFS
130149646052718950352949445413352868903108661859 (p48) * P78

p13566 Using B1=11000000, sigma=1967427651
5045470798912185236584829857820881628038969 (p43) * P73

p13603 By GNFS, 1 day
242815511986682711062713330659399733165428299624594537 (p54) * P61

p13644 By GNFS, 2 days
701456004046672773746909445953028358196829202932720373 (p54) * P65

p13654 Using B1=11000000, sigma=3780121612
4849577146743923098517072418818285047801 (p40) * P76

p13659 Using B1=11000000, sigma=3143598421
1486954434649970863829530935357997144845539 (p43) * P83

p13668 By GNFS, 4 days
1084034390004391628251682673730596967131902356379393053 (p55) * P66

p13680 By GNFS, 1 day
24106403125547900049895807691768488082041365204151 (p50) * P64

p13688 Using B1=11000000, sigma=3191416650
871763761400186023256578214719391328143741 (p42) * P74

p13692 Using B1=11000000, sigma=2448597478
28136761086505745058224229333923686136093 (p41) * P73

p13707 By GNFS
375650401402714851416300136916508620477348889 (p45) * P77

p13726 Using B1=11000000, sigma=2742855301
432237466215401940352718886276615657841 (p39) * P87

p13743 By GNFS, 2 days
305537985902787686404357759247685494832176343661741801673 (p57) * P65

p13744 Using B1=11000000, sigma=164735560
2727464623971949842556575261591613000753 (p40) * P81

p13753 By GNFS, 1 day
19727949322157588306258215470705250734702668244707 (p50) * P69

p13754 Using B1=11000000, sigma=237943320
207131541609189454721532825261417032102538181 (p45) * P81

p13760 By GNFS, 1 day
177921458009584691327333363438149409139147500337109631 (p54) * P64

p13770 By GNFS, 9 hours
491085183728795510481841415525580048793355200643475317 (p54) * P63

p13779 Using B1=11000000, sigma=3823191237
15560057749672473595202467946702003 (p35) * P88

p13790 Using B1=11000000, sigma=2462704723
338088763280772835118704879211358390763271 (p42) * P78

p13802 By GNFS, 1 day
20742946836584353495330096242542648919406431290093263 (p53) * P64

p13808 Using B1=11000000, sigma=1370012860
1282615040386069988075172584574220407961536257 (p46) * P81

p13816 Using B1=11000000, sigma=2385383109
12477235720416367382832850326495438889208207 (p44) * P77

p13887 By GNFS
195740249535638868414226131917692081750629583 (p45) * P79

p13897 Using B1=11000000, sigma=4218325959
6506776523227017502390037194512066443669 (p40) * P82

p13909 By GNFS, 2 days
1816176770348789243096565718316191159482175309231901 (p52) * P67

p13914 By GNFS
37264204944960866593578476063527642112337663404378393 (p53) * P71

p13951 Using B1=11000000, sigma=882623927
5499347502357318136966533769625080696607 (p40) * P80

p13958 By GNFS, 2 days
21583162911552406998275100840962302557264999748021969479847 (p59) * P68

p13985 Using B1=11000000, sigma=3088711672
226360414321611519318770929731760074751 (p39) * C86
Using msieve, 1h5m C86 =
30261865960494878472835765583224923778573 (p41) * P46
[/CODE]

In case you want to continue on the next block, i have already factored (but not send yet) the following.

14109 (c116)
14252 (c116)
14276 (c124)
14246 (c119)