Hi Alex,

Having had a look at this, I think you are right that there is a file deletion missing. This is, I think, a bug carried over from the Perl script. I know how to avoid this but in order to avoid fragmenting a discussion of factmsieve.py, I am going to deal with it on the thread where this script is being discussed.

Thank you for the bug report.

Brian Gladman

[quote=Brian Gladman;210779]Hi Alex,

Having had a look at this, I think you are right that there is a file deletion missing. This is, I think, a bug carried over from the Perl script. I know how to avoid this but in order to avoid fragmenting a discussion of factmsieve.py, I am going to deal with it on the thread where this script is being discussed.

Thank you for the bug report.

Brian Gladman[/quote]

Thanks. Glad to contribute. Do you have a link to that thread?? I would like to use the updated script when available instead of my current hack.

Update: Thread is here: [url]http://www.mersenneforum.org/showthread.php?t=12981[/url]

[quote=alexhiggins732;210782]Thanks. Glad to contribute. Do you have a link to that thread?? I would like to use the updated script when available instead of my current hack.

Update: Thread is here: [URL]http://www.mersenneforum.org/showthread.php?t=12981[/URL][/quote]

I've attempted to remove the duplicates issue but I haven't added your new features. One thing at a time :smile:

Can someone explain this?
I have discovered that for the below poly file changing the lpbr/a bounds(and not the mfbr/a bounds) doesnt increase sieving time at all. It just produces more relations. As far as I can see the only slowdown this would cause would be in filtering where many of the extra relations will get deleted. The filtering should succeed at the same time or earlier.

[CODE]n: 15005270032451638573915455345791420057258533783610684040867371242117841717882604739173311645250609083369820490996841195807
# norm 1.209676e-011 alpha -6.146674 e 2.353e-010
skew: 241423.98
c0: 34070890761106658404514898525
c1: -1164376566141885166380750
c2: -126310300464929863233
c3: -12137308509792
c4: -1579047782
c5: 300
Y0: -549327210782073570880624
Y1: 7930063283579
rlim: 10000000
alim: 10000000
lpbr: 28
lpba: 28
mfbr: 56
mfba: 56
rlambda: 2.5
alambda: 2.5
[/CODE]

[QUOTE=henryzz;213044]Can someone explain this?
I have discovered that for the below poly file changing the lpbr/a bounds(and not the mfbr/a bounds) doesnt increase sieving time at all.
[/QUOTE]

What do you mean? Can you post the different parameter combos and the respective sieving rates?

[quote=axn;213047]What do you mean? Can you post the different parameter combos and the respective sieving rates?[/quote]
Just modify the lpbr and lpba bounds up or down. The LatSieveTime outputed to ggnfs.log stays the same. I am using win32 binaries(on win64 grr...)
lpbr: 27
lpba: 27
LatSieveTime: 121
lpbr: 28
lpba: 28
LatSieveTime: 115
lpbr: 29
lpba: 29
LatSieveTime: 123
lpbr: 30
lpba: 30
LatSieveTime: 118

The variation in the timings is caused by me using the computer while the tests were running.

If you simply edit the test.poly file and the script goes on running (i.e. you didn't deliberately stop it), I suspect that the script doesn't care at all, because it only reads the test.poly file once at the start, then it keeps generating files called test.job from parameters sitting in the perl script's memory - you cannot easily modify that without stopping the script.
Even if you stop it, it may grab old parameters from a file .params (you can see it with "ls -lA").

Instead make a separate directory, make a few separate t27.poly, t28.poly etc files (with lpbr/a: 27 lpbr/a: 28), remove any
"q0: 3087501
qintsize: 33333" from them
and run them from separate command lines, like
[FONT=Arial Narrow]/yourPath/gnfs-lasieve4I13e -a t27.poly -f 30000000 -c 1000[/FONT]
[FONT=Arial Narrow]/yourPath/gnfs-lasieve4I13e -a t28.poly -f 30000000 -c 1000[/FONT]
(you have to fill in the blanks of your particular situation)

[quote=Batalov;213093]If you simply edit the test.poly file and the script goes on running (i.e. you didn't deliberately stop it), I suspect that the script doesn't care at all, because it only reads the test.poly file once at the start, then it keeps generating files called test.job from parameters sitting in the perl script's memory - you cannot easily modify that without stopping the script.
Even if you stop it, it may grab old parameters from a file .params (you can see it with "ls -lA").

Instead make a separate directory, make a few separate t27.poly, t28.poly etc files (with lpbr/a: 27 lpbr/a: 28), remove any
"q0: 3087501
qintsize: 33333" from them
and run them from separate command lines, like
[FONT=Arial Narrow]/yourPath/gnfs-lasieve4I13e -a t27.poly -f 30000000 -c 1000[/FONT]
[FONT=Arial Narrow]/yourPath/gnfs-lasieve4I13e -a t28.poly -f 30000000 -c 1000[/FONT]
(you have to fill in the blanks of your particular situation)[/quote]
i wasn't using the script
i was just editing a poly file i had created myself

if you just change lpbr/a then what is changing
is it puting any extra effort into factoring? i don't think so thats what mfbr/a is for i think
its just not binning relations that the large primes are too large in

On the other hand, I see you point more clearly now, I think.
Suppose you run the whole project twice - one with 27-bit lpba/r, another with 28-bit lbpr/a, and the times for each sieving chunk are roughly the same. Your two parallel projects will run roughly the same times then: [I]each chunk will run approximately the same time[/I] (this is your point, and this is roughly true, especially in some small range, e.g. 27 vs 28), will produce ~ twice as many relations for the 28, but that's ~ as much more relations as it will need. Or do you expect it to need only 1.9 more relations? Maybe, but maybe not. Somewhere for each number, there is a boundary that will make it run better with 27 or 28-bit (or other bit level).

Now, you do have a dilemma - one of them will run, say, 5% faster. In order to find which one you will need to run some simulations that will, say, take 5% of the future project. It's a wash for 120-digits gnfs, isn't it? You have to invest 5% of the time to win 5%.

If you do a 160-digit gnfs (250-diff.snfs) project, then you may run sims for 0.1-0.5% of the future time to save 5% of the time: chose the side, variate all prameters one by one to descend into a minimum (if you will find it in the noise). You can write a script that will run a Metropolis simplex random walk for you or something like. It may get lost unsupervised though (the sim data is noisy; what may seem a descent in parameter space may be a fluke).

NFS @ Home recently had done a few numbers with 31 and 32 bits and observed that the matrix size appeared to be unaffected (total wallclock time needs careful accounting, but was probably roughly the same? was it?).

[QUOTE]The variation in the timings is caused by me using the computer while the tests were running.[/QUOTE]
This is not the only reason. If you suggest that the timings actually [I]are[/I] the same, this appears to be false.
Well, run them 10 times and take an average (and minimize other activity) - and you will see that they will statistically significantly will be [I]not[/I] the same for 27, 28, 29 and 30. What about 26, 25? 31, 32? One (or two) of them will win (but that's not the end of simming)...

The whole objective function (total CPU-time) has a rather flat bottom with a lot of insignificant local minima, like a thimble. Not worth trying to hit the exact bottom, heh?

Thanks for the detailed reply Batalov. I have redone the timings with an idle cpu. I did them three times each this time. More didn't seem necessary as i was getting consistent results.
[code]lpbr/a: 24
LatSieveTime: 109
LatSieveTime: 109
LatSieveTime: 109
lpbr/a: 25
LatSieveTime: 110
LatSieveTime: 109
LatSieveTime: 109
lpbr/a: 26
LatSieveTime: 110
LatSieveTime: 110
LatSieveTime: 110
lpbr/a: 27
LatSieveTime: 111
LatSieveTime: 111
LatSieveTime: 111
lpbr/a: 28
LatSieveTime: 112
LatSieveTime: 112
LatSieveTime: 112
lpbr/a: 29
LatSieveTime: 113
LatSieveTime: 113
LatSieveTime: 113
lpbr/a: 30
LatSieveTime: 113
LatSieveTime: 114
LatSieveTime: 114
lpbr/a: 31
LatSieveTime: 114
LatSieveTime: 114
LatSieveTime: 114
lpbr/a: 32
LatSieveTime: 115
LatSieveTime: 115
LatSieveTime: 115[/code]The time taken increased by 5.5% by increasing lpbr/a from 24 to 32. That's not much difference in time and I would hope that some sieving would be saved by having the extra relations. My guess based on previous experiments would be that it would save more than enough. changing from 24 to 32 would be an extreme example though. I expect most of the useful extra relations would be quite a bit lower down than 32 bits.
These experiments make me think that the lpbr/a bounds don't make a huge difference in comparison to difference the mfbr/a bounds make.

The acid test is to run the whole way through factoring a number several times with different lbpr/a values. Then see which value takes less time (also compare total relations needed etc).

You probably want a small SNFS test case that takes a few hours so the whole series of tests doesn't take too long.

Chris K