Python Driver for GGNFS and MSIEVE - Page 36

Andi47 · 2010-04-05, 16:18

How come FactMsieve.py thinks that it needs 11M relations for this job?

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)

EdH · 2010-04-05, 20:06

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² * PrP113.

Take Care,
Ed

Brian Gladman · 2010-04-06, 06:59

Quote:

Originally Posted by Andi47

How come FactMsieve.py thinks that it needs 11M relations for this job?

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)

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

10metreh · 2010-04-06, 07:18

Quote:

Originally Posted by EdH

Interesting (to me at least) was the very next line, which produced 2² * PrP113.

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

Brian Gladman · 2010-04-06, 13:51

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

Brian

fivemack · 2010-04-06, 14:36

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.

Brian Gladman · 2010-04-06, 14:50

Quote:

Originally Posted by fivemack

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.

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

EdH · 2010-04-06, 15:20

Quote:

Originally Posted by 10metreh

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

The sequence is 257184 and the 2² * 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%.

fivemack · 2010-04-06, 16:00

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.

Brian Gladman · 2010-04-06, 16:39

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

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

EdH · 2010-04-06, 16:48

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

Should I interrupt it early (maybe at ~60%) and see if it will solve?

Take Care,
Ed

2010-04-05, 16:18	#386
Andi47 Oct 2004 Austria 2×17×73 Posts	How come FactMsieve.py thinks that it needs 11M relations for this job? 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) Last fiddled with by Andi47 on 2010-04-05 at 16:22 Reason: correction

2010-04-06, 13:51	#390
Brian Gladman May 2008 Worcester, United Kingdom 1024₈ Posts	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 Brian

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Msieve & ggnfs on MacOS	xilman	Msieve	8	2017-05-20 00:12
Factorizing with MSIEVE, GGNFS & Factmsieve.py	Romuald	Msieve	24	2015-11-09 20:16
Infinite loop for ggnfs or msieve	Greebley	Aliquot Sequences	4	2013-02-06 19:28
Error running GGNFS+msieve+factmsieve.py	D. B. Staple	Factoring	6	2011-06-12 22:23
A new driver? (or type of driver?)	10metreh	Aliquot Sequences	3	2010-02-15 15:57

2010-04-05, 20:06	#387
EdH "Ed Hall" Dec 2009 Adirondack Mtns 2×19×101 Posts	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² * PrP113. Take Care, Ed

2010-04-06, 14:36	#391
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 1100100011000₂ Posts	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=210^6 / 3.6M for 105..115 digits, using siever 12e 26 / alim=410^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.

2010-04-06, 16:00	#394
fivemack (loop (#_fork)) Feb 2006 Cambridge, England 2³·11·73 Posts	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.