How come FactMsieve.py thinks that it needs 11M relations for this job? :shock: With these parameters (that's the same what GGNFS uses as standard params) you should need somewhere between 4.7M and 5.0M (or at max. 5.1M?) relations.

Edit: It should be save to use even the first 5.2M relations, but with 12M relations it fails because it is *very* oversieved. (~250% is waaay too much)

Thanks 10metreh,

All worked fine with 5000000 and aliqueit is again on its way, having produced 8 more lines in quick succession . Interesting (to me at least) was the very next line, which produced 2[sup]2[/sup] * PrP113.

Take Care,
Ed

[quote=Andi47;210657]How come FactMsieve.py thinks that it needs 11M relations for this job? :shock: With these parameters (that's the same what GGNFS uses as standard params) you should need somewhere between 4.7M and 5.0M (or at max. 5.1M?) relations.

Edit: It should be save to use even the first 5.2M relations, but with 12M relations it fails because it is *very* oversieved. (~250% is waaay too much)[/quote]

It probably means that I got the approximation wrong for this lpbr/a. I'll check it out if we know the lpbr/a values.

Brian

[QUOTE=EdH;210672]Interesting (to me at least) was the very next line, which produced 2[sup]2[/sup] * PrP113.[/QUOTE]

Did you acquire the downdriver from that? It's a 1/2 chance.

There was an error in minrels for the lpbr value used.

Before I update the minrels values, does anyone think these are way out:[code]
lpbr/a digits minrels range (M)
25 ??? n < 100 1.6 .. 2.0
26 100 <= n < 110 3.8 .. 4.6
27 110 <= n < 130 7.3 .. 10.2
28 130 <= n ??? 18.0 .. 22.0
[/code] Brian

Hi Brian.

I think you may be using 25 and 26 a little early; my script uses

24 / alim=10^6 / 2M for 95..105 digits, using siever 12e
25 / alim=2*10^6 / 3.6M for 105..115 digits, using siever 12e
26 / alim=4*10^6 / 6.5M for 115..125 digits, using siever 13e

and I think 28 starts to beat 27 at about 135 digits, with 14e becoming relevant even a bit higher than that.

[quote=fivemack;210735]Hi Brian.

I think you may be using 25 and 26 a little early; my script uses

24 / alim=10^6 / 2M for 95..105 digits, using siever 12e
25 / alim=2*10^6 / 3.6M for 105..115 digits, using siever 12e
26 / alim=4*10^6 / 6.5M for 115..125 digits, using siever 13e

and I think 28 starts to beat 27 at about 135 digits, with 14e becoming relevant even a bit higher than that.[/quote]

Hi fivemack,

I just took these transition points straight out of the ggnfs default parameter file. Maybe this file is now outdated and needs updating? Is anyone holding responsibility for maintaining this file?

Aside from when to use an lpbr value do the minimum number of relations for each lpbr value look reasonable ?

Brian

[quote=10metreh;210711]Did you acquire the downdriver from that? It's a 1/2 chance.[/quote]
The sequence is [URL="http://factordb.com/search.php?se=1&aq=257184&action=last20&fr=&to="]257184[/URL] and the 2[sup]2[/sup] * PrP113 was at i1417.

Instead of dropping a 2, it picked up an extra and has been bouncing around with a couple 11s and 7s showing up and then leaving.

Right now factmsieve.py is running against a c99 and looking for ~1.5e6 relations. I think it's at about 80%.

I think your values are rather small for 26-bit large primes (I use 6.5 million), but then again I'm using the 26-bit large primes on much larger numbers. The 28-bit figures look about right.

I have an example of a 103-digit number, done with alim=rlim=2e6 and 25-bit large primes, which works with three million relations and doesn't work with 2.9 million. Will redo with 26-bit large primes and see what the numbers look like.

For a 116-digit number done with 26-bit large primes and alim=rlim=2^22-1, 5.8 million relations suffice and 5.7M is not enough.

Here are the full values (in millions) for each of the formula used vs lpbr/a:

[code] n/lpb 25 26 27 28 29

90 1.6 3.3 4.3 0.4 1.6
91 1.7 3.4 4.5 0.9 1.7
92 1.7 3.5 4.7 1.3 1.8
93 1.7 3.6 4.8 1.8 1.9
94 1.8 3.7 5.0 2.2 2.0
95 1.8 3.8 5.1 2.6 2.1
96 1.9 3.9 5.3 3.1 2.2
97 1.9 3.9 5.4 3.5 2.3
98 1.9 4.0 5.5 4.0 2.5
99 2.0 4.1 5.7 4.4 2.6
100 2.0 4.2 5.8 4.8 2.7
101 2.1 4.3 6.0 5.3 2.9
102 2.1 4.4 6.2 5.7 3.1
103 2.1 4.5 6.3 6.2 3.3
104 2.2 4.6 6.5 6.6 3.4
105 2.2 4.7 6.6 7.0 3.6
106 2.2 4.8 6.8 7.5 3.8
107 2.3 4.9 6.9 7.9 4.1
108 2.3 5.0 7.0 8.4 4.3
109 2.4 5.1 7.2 8.8 4.6
110 2.4 5.2 7.3 9.2 4.8
111 2.4 5.3 7.5 9.7 5.1
112 2.5 5.4 7.7 10.1 5.4
113 2.5 5.5 7.8 10.6 5.7
114 2.5 5.5 8.0 11.0 6.0
115 2.6 5.6 8.1 11.4 6.4
116 2.6 5.7 8.3 11.9 6.7
117 2.7 5.8 8.4 12.3 7.1
118 2.7 5.9 8.6 12.8 7.6
119 2.7 6.0 8.7 13.2 8.0
120 2.8 6.1 8.8 13.6 8.4
121 2.8 6.2 9.0 14.1 8.9
122 2.9 6.3 9.2 14.5 9.5
123 2.9 6.4 9.3 15.0 10.0
124 2.9 6.5 9.4 15.4 10.6
125 3.0 6.6 9.6 15.8 11.2
126 3.0 6.7 9.8 16.3 11.8
127 3.0 6.8 9.9 16.7 12.5
128 3.1 6.9 10.1 17.2 13.2
129 3.1 7.0 10.2 17.6 14.0
130 3.2 7.0 10.4 18.0 14.8
131 3.2 7.1 10.5 18.5 15.7
132 3.2 7.2 10.7 18.9 16.6
133 3.3 7.3 10.8 19.4 17.5
134 3.3 7.4 10.9 19.8 18.5
135 3.3 7.5 11.1 20.2 19.6
136 3.4 7.6 11.3 20.7 20.8
137 3.4 7.7 11.4 21.1 22.0
138 3.5 7.8 11.6 21.6 23.2
139 3.5 7.9 11.7 22.0 24.6[/code]These are the values used to detect when to start checking for sufficient relations (5% below the values given by my curve fitting to actual results).

Brian

I currently have a c102 that wants 7.695e+06 relations, with the following:
(test.job.T0)
[code]
n: 125848852344873821182935176269889165853000768321080305575556810844511203958944589164666166586778170007
c5: 1680
c4: -32366142
c3: -4093611520323
c2: 127183238401323497
c1: 2414216469912244485263
c0: -49580352156142857372849295
Y1: 15080116783
Y0: -37575837336895399464
skew: 36787.73
rlim: 2300000
alim: 1249999
lpbr: 26
lpba: 26
mfbr: 49
mfba: 49
rlambda: 2.6
alambda: 2.6
q0: 1250000
qintsize: 100000
#q1:1350000
[/code]Should I interrupt it early (maybe at ~60%) and see if it will solve?

Take Care,
Ed