GNFS estimates

[Andi47]

Originally Posted by smh

Change the last line of the script to:

# for($i = 0; $i < 5; $i++){sleep 1;print "\a";}

Thanks!

Originally Posted by 10metreh

I would guess those beeps are there to alert you trhat the factorization has finished. It was quite useful when I had a job that took 4 dependencies and I was not in the room as I usually am.

This is useful when I do just one factorization, but I don't want do be BEEPed out of bed when aliqueit.exe had called FactMsieve.pl, and the job finishes.

[henryzz]

Originally Posted by Andi47

I just recognized that the new FactMsieve.pl script beeps 5 time when it writes the time scale file - this would be quite annoying if that happens at night. How can I switch the beeps off? (I am not very familiar with perl)

i have got the opposite problem
my computer does not have a beeper
anyone got any suggestions except playing a sound through the speakers

[Joshua2]

Originally Posted by Jeff Gilchrist

That is cool, I have been adding my own change to the built-in estimate in the perl script, for C133-C135 gnfs jobs, I multiply by 2.5 and get almost an exact amount but that means I have to remember to change it before I run the script, etc...

This way is much better because I can tweak things on the fly and not have to worry about editing the script itself. Good job!

I've noticed that filtering fails many times before it finally succeeds, seemingly wasting a fair bit of time. Is there an easy way to make the perl script try 2x as big a space the first time? BTW, I just upgraded from to the latest SVN version of the script.

[10metreh]

Originally Posted by Joshua2

I've noticed that filtering fails many times before it finally succeeds, seemingly wasting a fair bit of time. Is there an easy way to make the perl script try 2x as big a space the first time?

Yeah, here's an adjusted script:

[Joshua2]

And where is the part I need to use? Or is this the latest SVN 345 that I should just make my changes to?

[10metreh]

Originally Posted by Joshua2

And where is the part I need to use? Or is this the latest SVN 345 that I should just make my changes to?

Ah, forgot this was the 340 one...

In Notepad or similar, do edit-find on $MINRELS in factMsieve.pl. The first time it occurs, you find

$MINRELS=int(0.2*1.442695*( (2**$LPBA)/$LPBA + (2**$LPBR)/$LPBR));

Replace the 0.2 with 0.4.

[Joshua2]

Cool, and will that make all the ranges double or just the first? Because it seems that if I do the first double, then the smaller size might be ok to not do too much oversieving.

[10metreh]

Originally Posted by Joshua2

Cool, and will that make all the ranges double or just the first? Because it seems that if I do the first double, then the smaller size might be ok to not do too much oversieving.

Oops, forgot what the question was, but make this change as well. My change waits longer before calling msieve, so that you don't have filtering early on when it's completely inappropriate. That should have about the same effect. If you still want the other change too, then look at you "def-par.txt" file. It's where factMsieve.pl gets its params from. An example line is:

gnfs,100,5,58,1500,3.0e-3,0.4,220,15,10000,2000,1800000,1800000,26,26,48,48,2.5,2.5,100000,4000000,300

The number in blue is the number of digits. The number in green is double the start of the first range. The number in red is the size of the ranges. So, for a 100-digit number, factMsieve.pl's first range is 0.9M-1M. If you change the number in red to 200000, the first range will be 0.9M-1.1M, the next will be 1.1M-1.3M, etc.

You can find the corresponding numbers in other lines and change these, too. I would not advise you to change the green number, however.

[Joshua2]

ok, I actually was thinking "first range will be 0.9M-1.1M, the next will be 1.1M-1.2M." is your change time between calling msieve first time or between each time? I'm thinking the between each times were probably found optimal, but the starting times are definetly not.

[10metreh]

Originally Posted by Joshua2

ok, I actually was thinking "first range will be 0.9M-1.1M, the next will be 1.1M-1.2M." is your change time between calling msieve first time or between each time? I'm thinking the between each times were probably found optimal, but the starting times are definetly not.

Undo my def-par.txt change if you want. Imagine you're doing a C100. You get "Found xxxxxx relations, need 1489501 to proceed". With my first adjustment, this becomes "Found xxxxxx relations, need 2979003 to proceed". This will hold msieve back until much later.

[Joshua2]

Ok, what I thinking is that I start 0.9M-1.2M maybe, and then go up by what it was before both for filtering and msieve like 1.3-1.4M next. Have you done any experimenting to see how many relations it needs compared to what it thinks?