Python Driver for GGNFS and MSIEVE - Page 40

scalabis · 2010-04-14, 07:49

Quote:

Originally Posted by Brian Gladman

Hi Ed,

That's because my code is not intended for Python 3.1 yet - in 3.1 the '_winreg' module has been renamed to 'winreg' so it might work if you take the underscore out.

Brian

Hi!

Im in the middle of a factoring using version 62 of your script.

I'm also using Python 3.1 and so far got no errors.

Should i stop, and downgrade to an earlier version of Python ?

Resuming with an earlier version on python should not affect the running of the script i suppose.

Wich version are you using right now for your development ?

Thanks, for all your work.

Regards,
scalabis

alexhiggins732 · 2010-04-14, 17:53

Quote:

Originally Posted by 10metreh

The parameters are horrible: they are taken from the file def-nm-params.txt, and they only go up to 155 digits. As a result, pol51 is trying to find polys with a normal score for a c155, but for a c190 the polys are much worse. So it won't find any polys and will thus go on searching further and further. However,

Code:

Searching leading coefficients from 3.97003e+10 to 3.97003e+10

shows that it's hardly searching at all: it is just searching for polys with the leading coefficient 39700300000, and that probably isn't a very good one. Does the figure of 3.97003e+10 change sometimes?

Actually, the first couple of entries are

Code:

Sun Apr 04 20:22:53 2010 -> Searching leading coefficients from 1 to 1000
Sun Apr 04 20:22:53 2010 -> pol51m0b -b rsa190.polselstaging1.624 -v -v -p 7 -n 7.12e+23 -a 0 -A 1> rsa190.polselstaging1.624.log
Sun Apr 04 20:22:53 2010 -> Searching leading coefficients from 1001 to 2000
Sun Apr 04 20:22:53 2010 -> pol51m0b -b rsa190.polselstaging1.624 -v -v -p 7 -n 7.12e+23 -a 1 -A 2>> rsa190.polselstaging1.624.log
Sun Apr 04 20:22:53 2010 -> Searching leading coefficients from 2001 to 3000
Sun Apr 04 20:22:53 2010 -> pol51m0b -b rsa190.polselstaging1.624 -v -v -p 7 -n 7.12e+23 -a 2 -A 3>> rsa190.polselstaging1.624.log
Sun Apr 04 20:22:53 2010 -> Searching leading coefficients from 3001 to 4000
Sun Apr 04 20:22:53 2010 -> pol51m0b -b rsa190.polselstaging1.624 -v -v -p 7 -n 7.12e+23 -a 3 -A 4>> rsa190.polselstaging1.624.log
Sun Apr 04 20:22:53 2010 -> Searching leading coefficients from 4001 to 5000
Sun Apr 04 20:22:53 2010 -> pol51m0b -b rsa190.polselstaging1.624 -v -v -p 7 -n 7.12e+23 -a 4 -A 5>> rsa190.polselstaging1.624.log
Sun Apr 04 20:22:53 2010 -> Searching leading coefficients from 5001 to 6000
Sun Apr 04 20:22:53 2010 -> pol51m0b -b rsa190.polselstaging1.624 -v -v -p 7 -n 7.12e+23 -a 5 -A 6>> rsa190.polselstaging1.624.log

and the last few lines before it crashed

Quote:

Tue Apr 06 15:58:12 2010 -> Searching leading coefficients from 3.97005e+10 to 3.97005e+10
Tue Apr 06 15:58:12 2010 -> pol51m0b -b rsa190.polselstaging1.624 -v -v -p 7 -n 7.12e+23 -a 3.97005e+07 -A 3.97005e+07>> rsa190.polselstaging1.624.log
Tue Apr 06 15:58:12 2010 -> Searching leading coefficients from 3.97005e+10 to 3.97005e+10
Tue Apr 06 15:58:12 2010 -> pol51m0b -b rsa190.polselstaging1.624 -v -v -p 7 -n 7.12e+23 -a 3.97005e+07 -A 3.97005e+07>> rsa190.polselstaging1.624.log
Tue Apr 06 15:58:12 2010 -> Searching leading coefficients from 3.97005e+10 to 3.97005e+10
Tue Apr 06 15:58:12 2010 -> pol51m0b -b rsa190.polselstaging1.624 -v -v -p 7 -n 7.12e+23 -a 3.97005e+07 -A 3.97005e+07>> rsa190.polselstaging1.624.log
Tue Apr 06 15:58:12 2010 -> Searching leading coefficients from 3.97005e+10 to 3.97005e+10

at this point the log file was 8.99 GB (9,659,040,027 bytes)

alexhiggins732 · 2010-04-14, 18:06

Quote:

Originally Posted by Brian Gladman

For (1) set VERBOSE = False (early in the script).

Brian

Would you recommoned that VERBOSE=FALSE be set in def run_pol5 perhaps right before while not pol5_term_flag and nerr < 2: to prevent all of the console output?

In regard to the logfile growing so large, VERBOSE=FALSE does not fix that issue as it seems that (suc = grep_f('success', pname + '.log')) actually searches the log file for a match.

Perhaps incrementally truncating the log file would resolve that issue. Better yet would be to save the polynomails to a separate file, like how it is done for MSIEVE poly selection ([jobname].dat.p.

Especially in this case, where it would prevent grepping an 8.99 GB log file that contains no matches.

10metreh · 2010-04-14, 18:16

Quote:

Originally Posted by alexhiggins732

Actually, the first couple of entries are
<snip>

I can't tell exactly what caused the crash, but you shouldn't be doing poly search on a c190 with useless parameters. Is this just a random number? If so, then you are wasting CPU time even if you run a search with good params.

Brian Gladman · 2010-04-14, 18:17

I am using Python 2.6 for development and I will move to 2.7 when it is released. I would really like to move to Python 3.1 but it was hard enough getting Linux folk to use even Python 2.6!

Alex: Unfortunately the log file for polynomial selection is not the global log file but one used only during the poly selection phase. It should be easy to turn off too much output to this file but I am away from my development machine right now so I cannot check this until I get back in a couple of days.

Brian

scalabis · 2010-04-14, 19:39

Quote:

Originally Posted by Brian Gladman

I am using Python 2.6 for development and I will move to 2.7 when it is released. I would really like to move to Python 3.1 but it was hard enough getting Linux folk to use even Python 2.6!

Alex: Unfortunately the log file for polynomial selection is not the global log file but one used only during the poly selection phase. It should be easy to turn off too much output to this file but I am away from my development machine right now so I cannot check this until I get back in a couple of days.

Brian

Hi!

Understood.

Everything around here back to Python 2.6 ...

Regerding Python 3.1, it is already released in a beta version.

When you release new versions of your script, may i suggest that you state the version of Python used for development/testing.

This can help i think.

Thanks again,
scalabis

alexhiggins732 · 2010-04-14, 20:12

Quote:

Originally Posted by 10metreh

I can't tell exactly what caused the crash, but you shouldn't be doing poly search on a c190 with useless parameters. Is this just a random number? If so, then you are wasting CPU time even if you run a search with good params.

It's RSA190 - http://en.wikipedia.org/wiki/RSA_numbers#RSA-190

Edit: By useless, since def-nm-params.txt file only contains parameters up to 155, your saying there is no way to find the polynomial.

EdH · 2010-04-16, 18:32

Quote:

Originally Posted by Brian Gladman

Hi Ed,

That's because my code is not intended for Python 3.1 yet - in 3.1 the '_winreg' module has been renamed to 'winreg' so it might work if you take the underscore out.

Brian

Worked great, Brian,

Code:

.  .  .
total time: 8.67 hours.
x86 Family 15 Model 2 Stepping 7, GenuineIntel
Windows-XP-5.1.2600-SP3
processors: 1, speed: 2.39GHz

Thanks!

Take Care,
Ed

EdH · 2010-04-18, 16:46

It just finished with another c106. This time it requested 4641000 relations, got 4672958 and succeeded fine.
Edit: version was 0.67 - machine was the one that had over-sieving trouble with the c106 a couple weeks ago (WinXP)

Thanks much!

Take Care,
Ed

ThomRuley · 2010-04-24, 18:52

I tried to run the program and keep getting the following error:

C:\GGNFS\example>..\factmsieve.py example
-> ________________________________________________________________
-> | Running factmsieve.py, a Python driver for MSIEVE with GGNFS |
-> | sieving support. It is Copyright, 2010, Brian Gladman and is |
-> | a conversion of factmsieve.pl that is Copyright, 2004, Chris |
-> | Monico. This is version 0.63, dated 30th March 2010. |
-> |______________________________________________________________|
-> This is client 1 of 1
-> Using 2 threads
-> Working with NAME = example
Traceback (most recent call last):
File "C:\GGNFS\factmsieve.py", line 1987, in <module>
read_parameters(fact_p, poly_p, lats_p)
File "C:\GGNFS\factmsieve.py", line 1187, in read_parameters
polyval = poly_p['m'] * polyval + coefvals[i]
TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'
siever terminated

Python 2.6
AMD processor
Windows XP
example.n method
Brian Gladman's GGNFS program

Any ideas?

Brian Gladman · 2010-04-24, 21:15

It looks like there is an error in the example.poly file as it cannot read the M value. Can you post its content?

2010-04-14, 18:17	#434
Brian Gladman May 2008 Worcester, United Kingdom 2²·7·19 Posts	I am using Python 2.6 for development and I will move to 2.7 when it is released. I would really like to move to Python 3.1 but it was hard enough getting Linux folk to use even Python 2.6! Alex: Unfortunately the log file for polynomial selection is not the global log file but one used only during the poly selection phase. It should be easy to turn off too much output to this file but I am away from my development machine right now so I cannot check this until I get back in a couple of days. Brian Last fiddled with by Brian Gladman on 2010-04-14 at 18:18

2010-04-18, 16:46	#438
EdH "Ed Hall" Dec 2009 Adirondack Mtns 2×3³×71 Posts	Another minor report It just finished with another c106. This time it requested 4641000 relations, got 4672958 and succeeded fine. Edit: version was 0.67 - machine was the one that had over-sieving trouble with the c106 a couple weeks ago (WinXP) Thanks much! Take Care, Ed Last fiddled with by EdH on 2010-04-18 at 16:59

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-24, 18:52	#439
ThomRuley May 2003 2³×31 Posts	I tried to run the program and keep getting the following error: C:\GGNFS\example>..\factmsieve.py example -> ________________________________________________________________ -> \| Running factmsieve.py, a Python driver for MSIEVE with GGNFS \| -> \| sieving support. It is Copyright, 2010, Brian Gladman and is \| -> \| a conversion of factmsieve.pl that is Copyright, 2004, Chris \| -> \| Monico. This is version 0.63, dated 30th March 2010. \| -> \|______________________________________________________________\| -> This is client 1 of 1 -> Using 2 threads -> Working with NAME = example Traceback (most recent call last): File "C:\GGNFS\factmsieve.py", line 1987, in <module> read_parameters(fact_p, poly_p, lats_p) File "C:\GGNFS\factmsieve.py", line 1187, in read_parameters polyval = poly_p['m'] * polyval + coefvals[i] TypeError: unsupported operand type(s) for *: 'NoneType' and 'int' siever terminated Python 2.6 AMD processor Windows XP example.n method Brian Gladman's GGNFS program Any ideas?

2010-04-24, 21:15	#440
Brian Gladman May 2008 Worcester, United Kingdom 1000010100₂ Posts	It looks like there is an error in the example.poly file as it cannot read the M value. Can you post its content?