I'm a bit confused about the new parameters POLY_MIN_LC and
POLY_MAX_LC. I guess in previous versions these parameters were determined automatically. Now they have to be specified manually.

Surely it was easier when the parameters were detected automatically? I can see that it's helpful to be able to specify the parameters manually, but shouldn't the default be to use an automatically determined range as in previous versions?

They weren't detected at all. With one thread it was sensible to set a time deadline on the search but with multiple threads it makes more sense to speciify the size of the search space.

I could add an overall elapsed time deadline so that the POLY_MAX_LC could be set very high with the search then being terminated if the time deadline is reached before the whole search space is completed.

But this won't work if the search is interrupted and then restarted later (unless I add more complexity by storing and retreiving elapsed search times).

Right now I would like to be sure that it is working before adding more 'bells and whistles' :-(

The POLY_MIN/MAX_LC values do have defaults so you don't have to play with them. But if the polynomial serach seems too short in time, just increase the POLY_MAX_LC value.

[QUOTE]They weren't detected at all. With one thread it was sensible to set a time deadline on the search but with multiple threads it makes more sense to speciify the size of the search space.[/QUOTE] Thanks for the explanation. That completely answers that one.

I found one small bug in the update related to our previous discussion. I'll post it in the thread dedicated to that.
[URL]http://www.mersenneforum.org/showthread.php?t=15658[/URL]

Note that there is a per-leading-coefficient time limit that is always applied, but if a range of leading coefficients is specified on the command line for NFS polynomial selection then the overall time limit for the search is not applied. You can still stop the search early by specifying a deadline with the '-d' switch.

If you are playing with the spq reading code, I am now using:

try:
with open('.last_spq' + str(100 * PNUM + j), 'r') as in_f:
try:
t = int(in_f.readline())
if t > qp:
fact_p['q_dq'][j] = (ql, t, qh)
except ValueError:
pass
except IOError:
pass

in the (as yet) unpublished version.

Thanks Jason - you must be psychic - you just answered a question that I was going to assk :-)

[QUOTE=Brian Gladman;264143]Sadly we are using different Python versions. Try the attached version.[/QUOTE]

Thanks Brian for this v.81 - it works perfect for me now :)
:bow::bow wave:

Only the Polynomial selection time and so the Total time looks curious.

[QUOTE]N = 28932964375472408051886765779259409234855451658876113961668576291342049987794596910585851 (89 digits)
Divisors found:
r1=6551232298747279617361 (pp22)
r2=5878130080532166726744361 (pp25)
r3=751330017694728904140304580860365836886931 (pp42)
Version: Msieve v. 1.49 (SVN 582)
[B]Total time: 363478.91 hours[/B].
Factorization parameters were as follows:
n: 28932964375472408051886765779259409234855451658876113961668576291342049987794596910585851
# norm 3.504786e-012 alpha -5.940915 e 5.564e-008 rroots 2
skew: 2434585.24
c0: -2047944524700007936665236205
c1: -709193758287723010446
c2: 76398319524725
c3: -45061922
c4: 168
Y0: -3622617308201805459308
Y1: 192219383131
type: gnfs
Factor base limits: 600000/600000
Large primes per side: 3
Large prime bits: 25/25
Sieved algebraic special-q in [0, 0)
Total raw relations: 1611897
Relations: 96622 relations
Pruned matrix : 65228 x 65456
Polynomial selection time: [B]363478.15 hours[/B].
Total sieving time: 0.73 hours.
Total relation processing time: 0.01 hours.
Matrix solve time: 0.01 hours.
time per square root: 0.01 hours.
Prototype def-par.txt line would be: gnfs,88,4,56,1500,0.0006,0.3,200,15,10000,500,600000,600000,25,25,43,43,2.2,2.2,10000
total time: [B]363478.91 hours[/B].
x86 Family 6 Model 23 Stepping 6, GenuineIntel
processors: 2, speed: 2.09GHz
Windows-Vista-6.0.6002-SP2
Running Python 2.6
[/QUOTE]

[QUOTE=Andi_HB;264188][QUOTE]Total time: 363478.91 hours.[/QUOTE][/QUOTE]

That looks like the current unix time in hours. Didn't subtract out the starting time, perhaps?

Yes, 'time zero' was not being set. I have corrected this and made a few other minor changes in the attached version.

I am a bit worried about filling up this site with many versions of the script but I can't find a way of removing old versions. Am I missing something?

Brian

[QUOTE]If you are playing with the spq reading code, I am now using:

try:
with open('.last_spq' + str(100 * PNUM + j), 'r') as in_f:
try:
t = int(in_f.readline())
if t > qp:
fact_p['q_dq'][j] = (ql, t, qh)
except ValueError:
pass
except IOError:
pass

in the (as yet) unpublished version. [/QUOTE]

Yes. The read_spq code was still not fixed as of factmsieve.81.py. The problem with the version in factmsieve.81.py was that the 'fact' code after the try/except was still executed even if the 'try' failed. In such a situation the variable 't' would be referenced even though it was undefined. This lead to a error "UnboundLocalError: local variable 't' referenced before assignment" The code that you gave above fixed the problem.

A mod (like me) can delete the old versions whenever you want; just let me know when to purge them.