[quote=Brian Gladman;211650]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[/quote]

Hi! :smile:

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

[quote=10metreh;211270]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[/code] 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?[/quote]

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

[/CODE]

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
[/QUOTE]

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

[quote=Brian Gladman;211277]For (1) set VERBOSE = False (early in the script).

Brian[/quote]

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.

[QUOTE=alexhiggins732;211753]Actually, the first couple of entries are
<snip>[/QUOTE]

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.

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

[quote=Brian Gladman;211760]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[/quote]

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

[quote=10metreh;211759]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.[/quote]

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

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.

[quote=Brian Gladman;211650]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[/quote]

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
[/code]
Thanks!

Take Care,
Ed

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

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?

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