also taking 3M - 4M

[QUOTE=JHansen;120434]If you have a cat, grep and tail available you can do

[CODE]cat *.cand | grep e-13 | sort -k 10 | tail[/CODE]

to automagically retrieve the lines containing the ten highest scores.

--
Cheers,
Jes[/QUOTE]That is almost the same command that I used when searching for the latest polynomial, but with these changes:

[CODE]cat *.cand | grep '_E ' | sort -n -k 10 | tail[/CODE]
Then if the Murphy_E goes over a power of ten (from 9e-13 to 1e-12 say), youu don't miss the larger values.


Paul

[quote]Then if the Murphy_E goes over a power of ten (from 9e-13 to 1e-12 say), you don't miss the larger values.[/quote]

In that case you want -g not -n; with just -n, 9e-13 sorts as greater than 1e-12.

Taking 10M to 12M. (the very first thing I will do with GGNFS)

P.S.: Beginner's question: What do the -p and -n options do?

[QUOTE=Andi47;120616]
P.S.: Beginner's question: What do the -p and -n options do?[/QUOTE]
-p specifies the number of factors in the high-order coefficient of the rational polynomial. -n specifies the largest norm allowed for polynomials that are generated. Notice that pol51opt has a smaller value for -n, because the first stage generates a huge number of somewhat good polynomials but the standards are higher when the polynomials are allowed to be optimized like pol51opt does.

This is a common problem with searching in general: you want to break things up such that each stage gets rid of the vast majority of choices, but every choice that's ignored could possibly have become much better if you stuck with it and tried to optimize it (which is expensive). One reason the polynomial selection tools run so fast is that the value of -n given to them is extremely stringent, so that very nearly nothing survives the first stage. Making -n a little bit bigger can give 100x the amount of output.

For example, when searching for a polynomial for a C100 the first stage runs in 5 seconds and the second stage runs in 30 seconds when using the recommended value of -n. Given that the sieving will take 4-8 hours, it would be nice to spend maybe 10 minutes instead of .5 minutes, looking for a better polynomial.

I picked the -n value for pol51m0b so that it would produce a comfortable number of outputs: I'd run a small search with -n 2e25, which produced several megabytes of output from a range of length 1000, ran polopt, then checked that a smaller value of -n gave a more reasonable number of outputs and hadn't killed off all the good hits from the larger n.

The parameters in polopt were again picked so that it ran at about the same speed as pol51m0b, with the Murphy value picked as the score for about the tenth-best polynomial coming out of a smallish run.

Anyone got 6e-13 or higher yet?

[QUOTE=Andi47;120616]Taking 10M to 12M. (the very first thing I will do with GGNFS)[/QUOTE]

Just a little note: I will usually see reservations made here, but if you make them on the factoring-forum thread

[url]http://www.mersenneforum.org/showthread.php?t=9730[/url]

then I can summarise them all in a convenient table and delete them, to make the thread tidier when the archivists from the planet Yammel come around in the twenty-ninth century to admire it. I thought asking the gerbils for editing power on one forum was already sufficiently presumptuous.

[QUOTE=fivemack;120625]I picked the -n value for pol51m0b so that it would produce a comfortable number of outputs: I'd run a small search with -n 2e25, which produced several megabytes of output from a range of length 1000, ran polopt, then checked that a smaller value of -n gave a more reasonable number of outputs and hadn't killed off all the good hits from the larger n.

The parameters in polopt were again picked so that it ran at about the same speed as pol51m0b, with the Murphy value picked as the score for about the tenth-best polynomial coming out of a smallish run.

Anyone got 6e-13 or higher yet?[/QUOTE]

I have found a nice poly at 6.74e-13 - posted in the factoring forum thread.

P.S.: With some good polynomials reported at >6e-13, it would be sufficient to set -e 6e-13 or so in the poly51opt line?

6.74e-13 is very impressive.

Yes, it would be fine to set -e 6e-13, but all it'll do is make the .cand file shorter rather than speeding up the run. I quite like setting the threshold so that the .cand file grows by a few lines an hour, so I know where everything's got up to at any moment.

I would be interested to see what the shape of the distribution of E-values both in absolute terms and as a function of x5 looks like, for which the smaller filter value is useful - if people have kept their .cand files, could I ask them to mail them (compressed) to [email]tom@womack.net[/email]

[QUOTE=fivemack;120854]Yes, it would be fine to set -e 6e-13, but all it'll do is make the .cand file shorter rather than speeding up the run.[/quote]

Making the .cand file shorter was exactly my intention with suggesting -e 6e-13.

[quote] I quite like setting the threshold so that the .cand file grows by a few lines an hour, so I know where everything's got up to at any moment.

I would be interested to see what the shape of the distribution of E-values both in absolute terms and as a function of x5 looks like, for which the smaller filter value is useful - if people have kept their .cand files, could I ask them to mail them (compressed) to tom (ät) womack (dot) net[/QUOTE]

OK, I will keep -e 4.5e-13. If you want, I can mail the zipped .cand files to you as soon as they are finished. (currently pol51opt is at ~70% for 11-12M and at ~11% for 10-11M, doing these ranges on two different nodes.)

P.S.: You should obscure your mail address to avoid massive spam (spambots).

[QUOTE=Andi47;120858]P.S.: You should obscure your mail address to avoid massive spam (spambots).[/QUOTE]OTOH, just get an efficient spam filter to read your mail for you. That way you get benefit from easy accessibility to your intended correspondents.

However, it does assume that the marginal cost of the bandwidth and cpu caused by the spam is minimal. It is for me, but YMMV.

Paul