- **YAFU**
(*https://www.mersenneforum.org/forumdisplay.php?f=96*)

- - **Odd result**
(*https://www.mersenneforum.org/showthread.php?t=20954*)

Odd resultLately I have been running the set of xyyx composites through YAFU using the nfs() command in an effort to identify the optimal polys as well as triage the input queue. Have completed several hundred numbers so far, and the results have been great. Sometimes the nfs.job file needs a bit of tweaking but I always end up with a usable poly and parameters. Subsequent test sieving then gives me an estimate for sieving time - a month, a season, two years. But then I encountered something strange (but no crash).
[url=http://www.factordb.com/index.php?showid=1100000000032304178]C189_147_41[/url] had a yield of zero in two of the best three polys, and only 1 relation with the best poly. But YAFU was attempting to sieve on the algebraic side. Nothing wrong with that, but obviously something was not right. Once I started test sieving this best poly with the -r flag, all was well - lots of relations were generated at a reasonable speed. Since this best poly matched what my hand calculations showed and I got a reasonable yield on the rational side, I went with it and moved on. But I thought this number may be an interesting edge case to report. With all three top polys, YAFU seemed to choose the wrong side to sieve, be it -a or -r. ETA: YAFU v1.34.5 from 2014. |

Thanks for the report, although I'm not able to duplicate the result. Here are the top 3 polys yafu found:
[CODE]gen: ======================================================== gen: best 3 polynomials: gen: ======================================================== n: 205451388964856467807686090421078666750691138189010020165236543387336128283211048921251478839880150378554118455189058228045898855699277369470472121604743428745579798048420314101101241961387 # 147^41+41^147, difficulty: 237.08, anorm: 6.37e+39, rnorm: -1.95e+45 # scaled difficulty: 237.08, suggest sieving algebraic side # size = 2.485e-12, alpha = -0.188, combined = 2.415e-13, rroots = 0 type: snfs size: 237 skew: 14.7100 c6: 1 c0: 10131387 Y1: -509111094534718962173411120845918138561 Y0: 1483273860320763 m: 44008401100288010210378427144625977757864842683924464711360809690583398911228987316128214321844953723667341332495287889981170421945600498539914605816457803581780075658984410989729763013655 n: 205451388964856467807686090421078666750691138189010020165236543387336128283211048921251478839880150378554118455189058228045898855699277369470472121604743428745579798048420314101101241961387 # 147^41+41^147, difficulty: 239.25, anorm: 9.94e+32, rnorm: -7.53e+52 # scaled difficulty: 242.56, suggest sieving rational side # size = 8.457e-17, alpha = 1.248, combined = 2.286e-13, rroots = 1 type: snfs size: 239 skew: 1.6280 c5: 147 c0: 1681 Y1: -58983677299744401560074115672359981890669066761 Y0: 218041257467152161 m: 34946929607508719506014770998825083593018841557045858886662564218589842554783361166467347325776095882039402635210917025426889596098707501970176176633141883727722787143948528425082301520455 n: 205451388964856467807686090421078666750691138189010020165236543387336128283211048921251478839880150378554118455189058228045898855699277369470472121604743428745579798048420314101101241961387 # 147^41+41^147, difficulty: 239.46, anorm: 5.73e+40, rnorm: -1.13e+45 # scaled difficulty: 239.46, suggest sieving algebraic side # size = 2.124e-12, alpha = -1.287, combined = 2.167e-13, rroots = 0 type: snfs size: 239 skew: 4.9033 c6: 243 c0: 3377129 Y1: -509111094534718962173411120845918138561 Y0: 494424620106921 m: 14669467033429336736792809048208659252621614227974821570453603230194466303742995772042738107281651241222447110831762629993723473981866832846638201938819267860593358552994803663243254337885 [/CODE] After finding these, it proceeded to trial factor. And although it determined that lpbr/lpba needed to be increased, each poly seemed to work fine. Ultimately it picked the first one with c6: 1 as the best after trial sieving. Afterward I ran some manual tests and it seems that the side was correct... I got better sec/rel figures for the algebraic side with the best poly (although the difference was small). Can you post the poly's yafu found? Was this on windows or linux? |

On my machine, I got the same polys in the same order, with sieving on the same sides as you. YAFU is calling the 14e siever, however the yield = 0 or 1 for all three polys.
Ultimately I too used the first poly, sieved by 15e on the rational side. It is a 31-bit job. It all seems a bit much for a SNFS 237 job. I am using an i5-3340M 2.7 GHz running Win 7 (64-bit). Let me run my poly on both the -r and -a sides and compare yields and speeds. |

I was able to reproduce this using windows. So it seems to be a problem with the windows lattice siever. Not sure if it is specific to the faster 64-bit asm-enabled ones or not. I'll try again with the older slower 32-bit windows sievers.
[edit] It fails on the algebraic side for both the win32 and x64 versions of the lattice siever. No idea why at this point. Linux version works fine on both sides. |

[QUOTE=bsquared;425222]
After finding these, it proceeded to trial factor. [/QUOTE] :razz: swellman's issue aside, this SNFS poly select stuff, going so far as to fiddle with the large primes, is quite impressive. Wonderful work Ben :smile: |

Many thanks bsquared. The sievers seem the next thing to investigate.
I will continue my test sieving and post results here. Sometimes it is the pilot and not the plane (i.e. me). Dubslow - yes it is very impressive. I have generated 300+ polys using YAFU. Only the crash recently fixed by Ben in development hits me occasionally, and that will be fixed in the next release. |

[QUOTE=Dubslow;425238]:razz:
swellman's issue aside, this SNFS poly select stuff, going so far as to fiddle with the large primes, is quite impressive. Wonderful work Ben :smile:[/QUOTE] Thanks! :smile: Let's not forget that this poly select stuff was hugely helped along by you! I hope someday you'll come back to help with development :razz: |

[QUOTE=bsquared;425242]Thanks! :smile:
Let's not forget that this poly select stuff was hugely helped along by you! I hope someday you'll come back to help with development :razz:[/QUOTE] I got it started perhaps, with some of the right structures and primitive parameter filling, but snfs.c was 98% you dude. Someday... when I've finally moved it all to git... |

[QUOTE=swellman;425240]
I will continue my test sieving and post results here. Sometimes it is the pilot and not the plane (i.e. me). [/QUOTE] No, I don't think this is your fault, and so far it doesn't look like yafu's (mine) either. I'm not sure anyone around can fix this plane... I know I can't :down: |

Test sieving of the best poly on my machine using a/rlim = 48M, 31 bit, sieved over range of 24,000,000-24,010,000 shows 0 relations on the -a side for both 14e and 15e sievers.
The -r side on 14e gives an ETA of 5461 hrs, 0.87 rel/spec_q 15e ETA of 6625 hrs, 1.73 rel/spec_q. Looks like something odd with the Windows ggnfs sievers. One for the ages. |

Is this abnormally slow? I forget what to expect for SNFS ~240...
For reference, here is the linux 14e siever on the -a side over the range 24M-24M+2k: [CODE]nfs: commencing [B]algebraic [/B]side lattice sieving over range: 24000000 - 24002000 gnfs-lasieve4I14e (with asm64): L1_BITS=15, SVN $Revision: 399 $ Warning: lowering FB_bound to 23999999. FBsize 1506969+0 (deg 6), 2638709+0 (deg 1) total yield: 3049, q=24002051 (0.07485 sec/rel) 124 Special q, 762 reduction iterations reports: 40449071->730667->657137->517658->348830->305514 Number of relations with k rational and l algebraic primes for (k,l)=: Total yield: 3049 0/0 mpqs failures, [COLOR="Red"]2843/2993[/COLOR] vain mpqs milliseconds total: Sieve 86570 Sched 0 medsched 37770 TD 16150 (Init 120, MPQS 2320) Sieve-Change 87730 TD side 0: init/small/medium/large/search: 2390 250 630 3120 280 sieve: init/small/medium/large/search: 1060 13240 380 28080 200 TD side 1: init/small/medium/large/search: 2000 550 1020 2930 440 sieve: init/small/medium/large/search: 550 13540 250 27980 1290 nfs: found 3049 relations, need at least 181892208 (filtering ETA: [B]3878h [/B]43m), continuing with sieving ... [/CODE] and 14e on the -r side: [CODE]nfs: commencing [B]rational [/B]side lattice sieving over range: 24000000 - 24002000 gnfs-lasieve4I14e (with asm64): L1_BITS=15, SVN $Revision: 399 $ Warning: lowering FB_bound to 23999999. FBsize 2637921+0 (deg 6), 1507120+0 (deg 1) total yield: 2856, q=24002051 (0.07599 sec/rel) 115 Special q, 687 reduction iterations reports: 32265958->797045->713569->473524->334518->285602 Number of relations with k rational and l algebraic primes for (k,l)=: Total yield: 2856 0/0 mpqs failures, [COLOR="red"]2608/2793[/COLOR] vain mpqs milliseconds total: Sieve 81590 Sched 0 medsched 37650 TD 15590 (Init 140, MPQS 1970) Sieve-Change 82210 TD side 0: init/small/medium/large/search: 2050 540 960 3040 570 sieve: init/small/medium/large/search: 420 12970 270 27410 960 TD side 1: init/small/medium/large/search: 1950 300 630 2910 380 sieve: init/small/medium/large/search: 1090 11840 350 26180 100 nfs: found 2856 relations, need at least 181892208 (filtering ETA: [B]4010h[/B] 51m), continuing with sieving ... [/CODE] Also, I highlighted what looks like a really high ratio of vain mpqs... but it's been too long since I ran the tools and I don't remember if this is a concern or not. |

All times are UTC. The time now is 04:45. |

Powered by vBulletin® Version 3.8.11

Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.