mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   YAFU (https://www.mersenneforum.org/forumdisplay.php?f=96)
-   -   Odd result (https://www.mersenneforum.org/showthread.php?t=20954)

swellman 2016-02-04 13:22

Odd result
 
Lately 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.

bsquared 2016-02-04 17:17

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?

swellman 2016-02-04 18:12

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.

bsquared 2016-02-04 18:32

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.

Dubslow 2016-02-04 18:34

[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:

swellman 2016-02-04 18:37

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.

bsquared 2016-02-04 18:43

[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:

Dubslow 2016-02-04 18:48

[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...

bsquared 2016-02-04 18:48

[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:

swellman 2016-02-04 20:19

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.

bsquared 2016-02-04 21:13

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.