I started yafu's nfs() on the c157 this morning. Currently running poly selection on 12 threads; looks like it will go for 25 hours before sieving. After 2 hours, the best poly is
# norm 3.004875e-15 alpha -6.840980 e 2.085e-12 rroots 5

I know we haven't done enough ecm yet but I'm determined to try out yafu on a big composite. :)

4500@11e6 and 7500@43e6 anyone?

I would do some of these myself if I had some free resources.

I've set sixteen threads running 3e7 ECM over the weekend, should manage about 8000 curves

new (but maybe not final) poly for the c157

[code][color=green]# sieve with ggnfs siever 14e on alg side from Q=15M to ??? (TBD)[/color]
# aq4788:2687
n: 1108732671439403475448401717724840921162347867281847674816074105186104781828508976628814340811626706734420375339078586851973913695141155181838952805734589439
# norm 3.224639e-15 alpha -7.361050 e 2.209e-12 rroots 5
skew: 5327358.14
c0: 139198309756081983997938024663195871200
c1: 569024993806450974585331332027264
c2: -35394607935565197980378092
c3: -60810626664068974000
c4: 1517755920101
c5: 561660
Y0: -1145698560676579962350184933143
Y1: 1476283037374888099
rlim: 30000000
alim: 30000000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.5
alambda: 2.5
[/code]

When sieving starts, it would make a nice 14e task for RSALS.

[QUOTE=Mini-Geek;256637]Explanation: you need a prime to break it, and the chance of a random number n being prime is about 1/log(n), but it must be of the form 4n+1 to break it, which is half of the primes, and the cofactor remaining after the 2 is odd, which doubles the chances, bringing you back to 1/log(n).
Based on this math and the assumption that 5 lines per digit during a downdriver run is a good average, (from my memory and looking at one big downdriver run that looks like a pretty good number - but all things considered, take these results with a grain of salt) I wrote the attached Python script. Run it with the current size as an argument, and it will tell you how far a downdriver run at that size can be expected to go to (it stops when the probability is 50%, not when the expected is 1, but if you want you can tweak the code).[/QUOTE]

I realized I made a rather large mistake in that math: it ignores that 3 can not be a cofactor of a downdriver, since otherwise it would be the 2*3 perfect driver. I also made it convert probability to expected before adding it as an "expected" value, and supported giving the current size as a float for improved accuracy (this should be the log[SUB]10[/SUB] of the current iteration; 1-2 decimal places or 4-5 significant digits is enough precision; it's only displayed to one decimal place).
With these improvements and the current size of 166.19, we have a 50.23% chance of this downdriver run making it to 134.2 digits. This is worse for us than my original estimate, but should be much more accurate. And anyway, if/when this downdriver run ends, there's a decent chance it will go to another downdriver or downguide. The new and improved script is attached. :smile:
More trivia: there is a 5.01% chance of it ending by 163.6 digits, and a 95.05% chance of it ending by 66.2 digits.

another improvement for c157 poly:

[code][color=green]# sieve with ggnfs siever 14e on alg side from Q=15M to 62M[/color]
# aq4788:2687
n: 1108732671439403475448401717724840921162347867281847674816074105186104781828508976628814340811626706734420375339078586851973913695141155181838952805734589439
# norm 3.880120e-15 alpha -5.936223 e 2.497e-12 rroots 3
skew: 762023.94
c0: -79274212071401638063304394637150500
c1: 246638895562014171201543535246
c2: -1072482077044679313538034
c3: 548452515633500515
c4: 7399402528048
c5: 111600
Y0: -1582810894664659927827648213917
Y1: 961751423467484513
rlim: 30000000
alim: 30000000
lpbr: 29
lpba: 29
mfbr: 58
mfba: 58
rlambda: 2.5
alambda: 2.5
[/code]

Indeed, I can queue part of this composite to RSALS, if it survives "enough" ECM (t50 @ B1=43e6 + t50 @ B1=11e7 ?).
But as usual, I don't want to squeeze out individuals that would like to participate in a team sieving :smile:

And maybe fivemack wants to do this number on his 48-core computer, in probably less than 100h wall clock time (it's six digits smaller than the C163 his computer crunched in less than 180 hours, several posts above) ?

[QUOTE=debrouxl;264050]Indeed, I can queue part of this composite to RSALS, if it survives "enough" ECM (t50 @ B1=43e6 + t50 @ B1=11e7 ?).
But as usual, I don't want to squeeze out individuals that would like to participate in a team sieving :smile:

And maybe fivemack wants to do this number on his 48-core computer, in probably less than 100h wall clock time (it's six digits smaller than the C163 his computer crunched in less than 180 hours, several posts above) ?[/QUOTE]

I think, bchaffin wants to use the c157 as a test case for yafu nfs(), see post#1244.

I have no desire to run GNFS on this number on my machine; I have several C15x from other aliquot sequences already queued up.

I would expect RSALS to be very much faster at sieving than a mere 48 1.9GHz Opteron CPUs, though I suppose many of the RSALS users are not using the efficient 64-bit Linux siever.

[quote]I have no desire to run GNFS on this number on my machine; I have several C15x from other aliquot sequences already queued up.[/quote]
ACK :smile:

[quote]I would expect RSALS to be very much faster at sieving than a mere 48 1.9GHz Opteron CPUs,[/quote]
Well, RSALS is a much smaller grid than NFS@Home is. Seriously, [i]at best[/i], RSALS is half an order of magnitude bigger than your computer, and the size of RSALS hasn't changed much in a while.

Case in point:
* in the past few days, RSALS has been crunching on 30-bit LPs SNFS tasks difficulty 228, 229 and 234, and the number of WUs (10K q values) in progress has been, besides short plunges or surges, between ~1600 and ~2000;
* for 30-bit LPs tasks, 10K q values complete in less than an hour on recent computers.
Based on these numbers, I'd say that the RSALS grid is currently equivalent to less than 100 full-time cores.

[quote]I suppose many of the RSALS users are not using the efficient 64-bit Linux siever.[/quote]
Indeed, RSALS sends a single 32-bit siever binary (which hasn't changed since August 2009) for each of the supported OS versions.


With the increasing power of individual factorers' computers, we'll have to add the 15e siever by late 2011 or early 2012. After this addition, RSALS should still not be overlapping with NFS@Home, because NFS@Home usually sieves Cunningham composites, while RSALS sieves OddPerfect (Brent composites) and Aliquot, occasionally Near-repdigit and XYYXF composites.

[QUOTE=Andi47;264054]I think, bchaffin wants to use the c157 as a test case for yafu nfs(), see post#1244.[/QUOTE]

I'm not too attached. I mainly wanted to test out the multi-threaded polynomial search, which worked great but didn't beat the poly that jrk posted. I could tackle the c157 with 11 cores, or if folks want to do a team sieve that's fine too.