![]() |
I've nearly finished ECMing 22199431^29-1 so I'll reserve another for ECM (and SNFS if necessary):
17761^53-1 Chris |
16217^53-1 is done: [code]
p80 factor: 86772614119877518598521554735597213021089055346722044586104730227549550843099253 p139 factor: 9552366319330267184545546679466060233277293220097359222081989423189573348281813264571137466751907623771478827246777986497336881773415595057 [/code] And 22199431^29-1 survived ECM so is now being sieved. Chris |
[QUOTE=chris2be8;413831]I've nearly finished ECMing 22199431^29-1 so I'll reserve another for ECM (and SNFS if necessary):
17761^53-1 Chris[/QUOTE] That factored: [code] ********** Factor found in step 2: 105712099946023601317435435761612562734762890406881443 Found probable prime factor of 54 digits: 105712099946023601317435435761612562734762890406881443 Probable prime cofactor 887575477820895463717193816375796224704492277839834161323259469158770965330657874072970634431461421183066730864448442558622337904211585187766807295314918691930236183431 has 168 digits [/code] So reserving another for ECM (and SNFS if necessary): 17041^53-1 Chris |
Oscar aka Lorgix found a factor of [URL="http://factordb.com/index.php?id=1100000000378750542"]3541^67-1[/URL] with ECM then finished it with GNFS
|
I won't have finished ECMing 17041^53-1 before 22199431^29-1 starts LA so I'll reserve the last one RichD ECMed for SNFS:
16231^53-1 Chris |
22199431^29-1 is done: [code]
Wed Nov 4 08:06:51 2015 p71 factor: 24108175926703930592719372312486686211332973181273488686889753207576817 Wed Nov 4 08:06:51 2015 p136 factor: 2067317939925575039903922821387526945931977782056000068910462701883585412232894091181141831120724639633327671585823476791259173732130977 [/code] NB. The latest msieve says pnn instead of prpnn which confused my version of factMsieve.pl (it searched for prp and didn't find it). I think I've fixed it, I'll know for sure when the next number is done. Chris |
I've nearly finished ECMing 17041^53-1 so I'll reserve another for ECM:
1237^71-1 Chris |
16231^53-1 is done: [code]
p73 factor: 1835489403752257826335305231062300722751288914287339549029854984350235181 p147 factor: 472312369158180099749238582722641485190720099773517410597742148875031308918273466680891727557175353901530312368287153968469885171377714324863696853 [/code] Chris |
1237^71-1 is done: [code]
********** Factor found in step 2: 1316830732558187278200529271776496710622227711387 Found prime factor of 49 digits: 1316830732558187278200529271776496710622227711387 Prime cofactor 7522009303601711986497193708777787665069134629711949647654768074861164638093335162152596309508770483085643106388442258810089 9904690883760595916485248306445921490593 has 164 digits [/code] Which makes my new GPU seem worth the trouble of setting it up. So I'll reserve another to ECM: 26849^47-1 Chris |
I've finished ECMing 26849^47-1 (it's now queued for SNFS) so I'll reserve another:
26861^47-1 Chris |
Can this be improved upon?
[QUOTE=RichD;410123]I'm also starting some ECM work on:
1327736012762191^17-1[/QUOTE] I’ve completed ECM for (1327736012762191^17-1)/(1327736012762191-1) to 2/9 of the C242. This appears to be large enough that degree halving should have some benefits. The traditional sextic (which is a much larger polynomial) sieves poorly. Don’t even consider a quartic for this size number. (pitiful sieving) Both of these would need more ECM work. So now we have the following octic polynomial: [CODE]n: 93279832932678885982491327274510953769646671804250585173949381396533884838015343380578179958902524702743577609136955094165823424785868918382341305541015034575413635998174157065849573034448811318011391066252444362245200432150814809755443305857 skew: 1 c8: 1 c7: 1 c6: -7 c5: -6 c4: 15 c3: 10 c2: -10 c1: -4 c0: 1 Y1: 1327736012762191 Y0: -1762882919585641022025519120482[/CODE] It turns out it sieves better on the algebraic side but the yield is nowhere near the desired 2.0 (actually 0.4). I’ve tried the 15e siever but the best performing parameters are what would be expected for a quintic SNFS-242 with 14e. With the poor yield, special-q would have to go deep to get enough relations. Without looking into this in much detail I wonder if, say, 3/4 of the relations would be gathered using the -a switch and the remainder with -r, then combine. Is there something better to look into or is it just the nature of this beast? |
| All times are UTC. The time now is 22:43. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.