G197
 

After more than two months of polynomial searching (contributed particularly by bdodson), and trial-sieving about 200 candidates, I've come up with what I think is the best polynomial for the 197-digit cofactor of 7^374+1, namely

[code]
# norm 1.748068e-19 alpha -8.861264 e 5.627e-15 rroots 3
skew: 364380251.54
c0: 4348541943020307432834531575431557582005296059208
c1: -626624655839261549230516300510260244794696
c2: 1853996443926010028387831301890264
c3: 19250478525296406872044059
c4: -6615815776509564
c5: 7851060
Y0: -95132171124790181824704637743510497691
Y1: 2130029229416788788241
n: 61173781879800813987062254208969082152381029438415262556799619943895079615422740343994343770534689647933527791161943080608113058309486560791550732809340767016424578028793088881479019117986214217881
lpbr: 32
lpba: 33
mfbr: 64
mfba: 96
rlambda: 2.6
alambda: 3.6
alim: 240000000
rlim: 240000000
[/code]

and a measurement of the correlation between Murphy score and time-to-sieve metrics which is much looser than I had expected.

We'd need to use the 16e siever, and start by sieving 80M to 400M. Yield is about two relations every three CPU-seconds (on 1900MHz Opteron), so that will be about a billion CPU-seconds in total on such a machine. This is a job large enough that only people with 64-bit Linux machines will be able to contribute usefully; I would also recommend dividing your range into quite small intervals, since I saw a 0.3% rate of hanging per 2kQ in gnfs-lasieve4I16e during the trial-sieving stage.

I suspect that the resources of the forum will be enough to get the sieving done by Christmas; and indeed it was done by 25 October, mostly thanks to bdodson.

[b]Reservations[/b]
fivemack 08/07 80M - 89.6M (done 07/08)
fivemack 07/08 89.6M - 100.0M (done 27/09)
bdodson 15/07 200M - 300M (done mid-August, uploaded around 14 September)
bdodson 24/08 300M - 350M (uploaded 15 September)
bdodson 14/09 350M - 400M (uploaded 28 September)
bdodson 20/09 100M - 150M (uploaded 6 October)
bdodson 20/09 150M - 190M (extended 6 October from 150-170; uploaded 14 October)
fivemack 27/09 190M - 200M (finished 0130 25 October)
bdodson 07/10 400M - 450M (uploaded 24 October)

[QUOTE=fivemack;265821]After more than two months of polynomial searching (contributed particularly by bdodson), and trial-sieving about 200 candidates, I've come up with what I think is the best polynomial for the 197-digit cofactor of 7^374+1, namely

[code]
# norm 1.748068e-19 alpha -8.861264 e 5.627e-15 rroots 3
skew: 364380251.54
c0: 4348541943020307432834531575431557582005296059208
c1: -626624655839261549230516300510260244794696
c2: 1853996443926010028387831301890264
c3: 19250478525296406872044059
c4: -6615815776509564
c5: 7851060
Y0: -95132171124790181824704637743510497691
Y1: 2130029229416788788241
n: 61173781879800813987062254208969082152381029438415262556799619943895079615422740343994343770534689647933527791161943080608113058309486560791550732809340767016424578028793088881479019117986214217881
lpbr: 32
lpba: 33
mfbr: 64
mfba: 96
rlambda: 2.6
alambda: 3.6
alim: 240000000
rlim: 240000000
[/code]

and a measurement of the correlation between Murphy score and time-to-sieve metrics which is much looser than I had expected.

We'd need to use the 16e siever, and start by sieving 80M to 400M. Yield is about two relations every three CPU-seconds (on 1900MHz Opteron), so that will be about a billion CPU-seconds in total on such a machine. This is a job large enough that only people with 64-bit Linux machines will be able to contribute usefully; I would also recommend dividing your range into quite small intervals, since I saw a 0.3% rate of hanging per 2kQ in gnfs-lasieve4I16e during the trial-sieving stage.

I suspect that the resources of the forum will be enough to get the sieving done by Christmas.

[b]Reservations[/b]
fivemack 08/07 80M - 89.6M[/QUOTE]


I am a bit surprised that the rational and algebraic factor bases have the
same size.. Did you run some trial sieving? I would have guessed that the
algebraic side would have the larger factor base.

[QUOTE=R.D. Silverman;266118]I am a bit surprised that the rational and algebraic factor bases have the
same size.. Did you run some trial sieving? I would have guessed that the
algebraic side would have the larger factor base.[/QUOTE]

To offset this, three large primes are allowed on the algebraic side but only two on the rational side. This allows for a smaller factor base and therefore lower memory use during sieving. However, I have noticed that for NFS@Home SNFS targets this does increase the number of duplicate relations somewhat from typically ~23% for two large primes on both sides to ~30% for three large primes on one side.

[QUOTE=fivemack;265821]After more than two months of polynomial searching (contributed particularly by bdodson), and trial-sieving about 200 candidates, I've come up with what I think is the best polynomial for the 197-digit cofactor of 7^374+1, ...

We'd need to use the 16e siever, and start by sieving 80M to 400M. ...[/QUOTE]
I'll start with 200M-300M, while our disks are crowded with data for the matrices
on two completed sieving tasks. -Bruce

[QUOTE=bdodson;266404]I'll start with 200M-300M, while our disks are crowded with data for the matrices
on two completed sieving tasks. -Bruce[/QUOTE]
This one also uses -M 1 (like 2p956)? And we're only sieving on the
algebraic side? -bd

Yes: sieve on the algebraic side only. I .think. that -M 1 is set by default, but there's no harm in using it if it isn't.

[QUOTE=fivemack;266476]Yes: sieve on the algebraic side only. I .think. that -M 1 is set by default, but there's no harm in using it if it isn't.[/QUOTE]
Yes (same as it was for 956 ...). None of the first 1000 tasks of width 4K
from 200M-210M got hung (with Serge's March 2010 binary). So far, so good.

-Bruce

[QUOTE=fivemack;265821]After more than two months of polynomial searching (contributed particularly by bdodson), and trial-sieving about 200 candidates, I've come up with what I think is the best polynomial for the 197-digit cofactor of 7^374+1, namely

[snip]

We'd need to use the 16e siever, and start by sieving 80M to 400M. Yield is about two relations every three CPU-seconds (on 1900MHz Opteron), so that will be about a billion CPU-seconds in total on such a machine.

[snip]
[/QUOTE]

As a sanity-check, can somebody tell me what yield I should be seeing (in relations/q, not relations/sec). I did a trial-sieve with this .poly file of just 1000, starting at 341M (i.e. -f 341000000 -c 1000), and I got way fewer relations than I would have expected. WAY fewer. Can anybody tell me how many I should have gotten?

I'm running the range at the moment to check; it's not complete yet, but I would expect about 1800 relations by simple extrapolation.

edit: job complete; total yield: 2183, q=341001007 (1.72407 sec/rel)

The build of gnfs-lasieve4I16e that I'm using is at [url]http://www.chiark.greenend.org.uk/~twomack/gnfs-lasieve4I16e[/url]

[QUOTE=fivemack;266672]I'm running the range at the moment to check; it's not complete yet, but I would expect about 1800 relations by simple extrapolation.

edit: job complete; total yield: 2183, q=341001007 (1.72407 sec/rel)

The build of gnfs-lasieve4I16e that I'm using is at [url]http://www.chiark.greenend.org.uk/~twomack/gnfs-lasieve4I16e[/url][/QUOTE]

Okay, thanks for that. There's definitely something wrong on my end. I think I built the gnfs-lasieve* binaries a long time ago, so they're using an old version of the source. Guess I'd better update to latest and rebuild them.

[QUOTE=fivemack;266672] The build of gnfs-lasieve4I16e that I'm using is at [URL]http://chiark.greenend.org.uk/~twomack/gnfs-lasieve4I16e[/URL][/QUOTE]

That link doesn't work for me.

[b]fivemack: fixed now[/b]

I get a page saying: [quote] Sorry, wrong server address
chiark's webserver is at [url]http://www.chiark.greenend.org.uk[/url].

Please add the www to the URL you were using and try again; if you got to this page by following a link please inform the owner of the page you came from so that they can correct the link.
Ian Jackson [email]webmaster@chiark.greenend.org.uk[/email].
[/quote]
Chris K