20101105, 15:09  #144 
"Ed Hall"
Dec 2009
Adirondack Mtns
3,253 Posts 
Once this iteration is factored, is it a freeforall to factor the next? Or, is there some coordinated effort to perform the (hopefully) trivial factoring of the next few composites?
Would it be rude for those not postprocessing to still run curves, or just time wasting. If a factor was happened upon, via the additional curves, would that be good or bad? I am not doing the above, but I'm restarting some machines after a trip and the questions came to mind. 
20101105, 16:26  #145  
Account Deleted
"Tim Sorbera"
Aug 2006
San Antonio, TX USA
1000010101011_{2} Posts 
Quote:
Quote:
They wouldn't be harmful, after all they just might find a factor and save us the extra couple days of postprocessing, but the chances that you'd find one in this time period after the ECM we've given it is extremely slim, and whether you do the ECM or not, we'll have the answer very soon. If you were to find it via ECM now, then all the work done on the GNFS would have been wasted. But the end result is still that we have the factors. Last fiddled with by MiniGeek on 20101105 at 16:34 

20101105, 16:48  #146 
Sep 2004
2·5·283 Posts 
You can run some ecm curves on this c170 but you have less than 71 hours until I get the factors from the postprocessing.

20101105, 19:05  #147 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
29×313 Posts 
As shown by Tom's and Greg's tests, larger density filtering attempts will need
1. more relations to succeed (there's no free lunch) 2. more memory to run 3. but will be faster (in this size range) For every particular algebra setup, there's an optimum in the sky (probably the largest+densest matrix that still fits the memory and converges in filtering). The minimum total factoring time is even trickier  but doesn't have to be perfect if all participants have something else to switch to, anyway. I'd suggest having a few precompiled binaries at hand and try e.g. first, TD 100, and if it doesn't converge or the resulting matrix doesn't fit the memory, then fallback to 90 or 80. The good ol' 70 is also nothing to sneeze at. Sometimes it is simply the best (especially for aliquot runofthemill transient gnfs projects). So, the algorithm: compile TD 70, 80, 90, 100, and also make of the notLARGE_BLOCKS, just in case (because stages are separate, you can combine these two dimensions). Before every compilation, insert a selfdescripting string in logprintf("Msieve 1.47..."), ok? We have this for example (B+D): Sun Oct 10 05:03:41 2010 Msieve v. 1.47 SVN379 LARGE_BLOCKS zlib density100 Sun Oct 10 05:03:41 2010 random seeds: 3abfbd9f cd113da7 Sun Oct 10 05:03:41 2010 factoring 2760869837544182879281843314...95882573313215568949924071 (211 digits) Sun Oct 10 05:03:42 2010 searching for 15digit factors... etc My 2 cents. Last fiddled with by Batalov on 20101105 at 19:07 Reason: /awfully long [and useless] string clipped/ 
20101105, 23:49  #148 
Tribal Bullet
Oct 2004
3,527 Posts 
Looks like the filtering needs general command line argument parsing. Command lines for filtering and LA are in my queue.
The target density defaults to 70 because it is a good compromise that keeps the memory use down while still producing a matrix that is small (enough) and sparse. My guess is that you have to be sieving with multiple machines, and generate a very large matrix, for a higher target density to reduce the LA time by more than the extra calendartime spent sieving. Last fiddled with by jasonp on 20101105 at 23:57 
20101106, 01:26  #149  
Oct 2004
Austria
100110110010_{2} Posts 
Quote:


20101106, 01:43  #150  
Oct 2004
Austria
2×17×73 Posts 
Quote:
personally I am currently running sequence 10212 and currently I keep encountering cofactors around c140 to c145 (I know, that's quite a bit smaller than c170, but that's the difference between home computing and team computing.). My approach is the following: 1.) ECM to the desired extent. (e.g. for a c141 I do full B1=11e6 and maybe 500@43e6) 2.) Poly search. In parallel (on the idle threads of my i7) I do P1 and p+1 to e.g. B1=5e9 and B2=5e15, followed by yet more ECM, until poly search has finished. 3.) sieving. And only sieving. No ECM at this time. Not a single curve. 4.) postprocessing. At this time I might consider ECMing something else, but not the cofactor of the current cofactor of the sequence, hence I would consider it wasteful if I find no ECM factor, and very annoying if I would find an ECM factor just a few hours before a twotothreeweeksGNFS finishes to output the factors. Last fiddled with by Andi47 on 20101106 at 01:45 

20101106, 01:58  #151 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
29×313 Posts 

20101108, 11:19  #152 
Sep 2004
2830_{10} Posts 
LA will finish within 4 hours.

20101108, 17:43  #153 
Sep 2004
2·5·283 Posts 
Code:
prp55: 5020628089729196540791781957106211235328810013516737941 prp115: 6236805693823202812256436162373797339317645025210784211942726700957117792931768486741474427658616159852603436208839 Last fiddled with by em99010pepe on 20101108 at 17:45 
20101109, 07:39  #154  
"Frank <^>"
Dec 2004
CDP Janesville
2×1,061 Posts 
Quote:
Quote:
I would have been bummed if it had turned out like my c146: three weeks to find out it was p43*p103. Now that I've got it figured out, I can put an ECM server up on the next large composite. That'll make the job easier to track.... 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Team sieve #44: C158 from 4788:i5212  RichD  Aliquot Sequences  29  20140413 01:55 
Team sieve #42: C161 from 4788:i5193  RichD  Aliquot Sequences  49  20131217 12:27 
Team sieve #34: c148 from 4788:i2910  jrk  Aliquot Sequences  14  20120224 15:10 
ECM work on 4788:2549.c170  schickel  Aliquot Sequences  51  20110105 02:32 
Team sieve #3: c131 from 4788:2382  10metreh  Aliquot Sequences  39  20090503 14:02 