Current Work & A Query

[R.D. Silverman]

It appears that Greg and Bruce have some very large resources
available to them. (very nice!) and are tackling some very hard numbers.
This is terrific. Although I'd like to see them do some of the first few holes,
I understand their reasons for not tacking the current "wanted" lists and it
seems quite reasonable.


I'd like to see an effort to finish base 2 to 800 bits.
I am currently sieving 2,1101+ (1/3 sieved) and will then do 2,1104+.
After that, I will sieve 2,1538M. [but may need help with the LA; my biggest machine has only 2G].

The remaining 2 numbers less than 800 bits are

2,799+ (SNFS), 2,1538M (I will do; SNFS), 2,1586L (GNFS!), 2,1598L (??),
and 2,1598M (GNFS),


I exclude for the moment the base 2 numbers with composite exponents
above 800 bits that have a usable algebraic factor. I will do some of these
eventually.

The Query:

An interesting question. Is 2,1598L C171 (799 bits by SNFS) easier by
SNFS or GNFS? It is close. I suspect the former.

Also an observation:

Base 11 has been relatively neglected....

[xilman]

Originally Posted by R.D. Silverman

After that, I will sieve 2,1538M. [but may need help with the LA; my biggest machine has only 2G].

I should be able to step in if needed.

Paul

[fivemack]

Base 11 is a bit neglected, but 5,331[+-] are both only just over 768 bits and look like reasonable personal-snfs targets; also 7,277[+-] at 778 bits.

2,821- is the only number on the wanted list that's not claimed, and is I suppose a natural target for mersenneforum; a bit more work than 3+512, but 3+512 doesn't seem to have been a serious strain. I've reserved it with Sam, and will do some experimental sieving to get parameters tonight.

x^6-2 must be the right polynomial, though I'm surprised to find that by at least one measure () it's worse (score 1.651) than 9x^6+1 (score 1.958). I don't know how you'd account for the contribution from real roots, which x^6-2 has and 9x^6+1 lacks.

[bdodson]

Originally Posted by R.D. Silverman

2,799+ (SNFS), 2,1538M (I will do; SNFS), 2,1586L (GNFS!), 2,1598L (??),
and 2,1598M (GNFS),

I exclude for the moment the base 2 numbers with composite exponents
above 800 bits that have a usable algebraic factor. I will do some of these
eventually.

an observation:

Base 11 has been relatively neglected....

The new "who's doing what?" includes

11,251-	c208	Childers/Dodson
2,1101+	c211	Silverman
  ...
2,788+	c219	NFSNET
6,313-	c227	NFSNET
10,241-	c229	NFSNET

a very hard base-11 (a mistake on my part, I thought that is was
still a c258, but ecm hapened to it; so we're doing the c208 anyway).

The 788+ was a last minute suggestion from Sam, but it was clearly
too small, under two weeks of sieving (with lots of turn-around effort
for NFSNET). We're doing 10,241- c229, difficulty 241 mostly as a warm-up
(and base-10 affirmative action), difficulty approaching 245 seems to
be a more likely range. Note also that NFSNET did do two of the last
three under 768-bits; so it's not like we haven't been doing our share
of the 1st five holes. As you've noted, the new Childers/Dodson target
range is above difficulty 260; but we did do a couple from the 1st five
on the way up (notably 12,241 C260 Childers/Wackerbarth/Dodson).
I'm on the last range of width 20M (out of 30M-250M) on 3,547-, after
which I'll have four large matrices to deal with --- pending full production
and data exchange to Greg's new machine, sieving is still way out-running
our matrix resources. We clearly ought to be sieving harder/larger numbers
so as to give the matrix queue a chance to clear. -Bruce

[fivemack]

I wouldn't be very optimistic that sieving harder numbers will give the matrix queue a chance to clear, unless you deliberately use sub-optimal large prime bounds: I get the strong impression that we're at a stage where harder numbers will have much harder matrices, and msieve is already taking a couple of months on four cores to handle a 20M matrix.

Or possibly block-Weidemann will be available by the time the sieving for a 900-bit number has finished, in which case all bets are off.

[bsquared]

Originally Posted by fivemack

Base 11 is a bit neglected, but 5,331[+-] are both only just over 768 bits and look like reasonable personal-snfs targets.

2,821- is the only number on the wanted list that's not claimed, and is I suppose a natural target for mersenneforum; a bit more work than 3+512, but 3+512 doesn't seem to have been a serious strain. I've reserved it with Sam, and will do some experimental sieving to get parameters tonight.

x^6-2 must be the right polynomial, though I'm surprised to find that by at least one measure () it's worse (score 1.651) than 9x^6+1 (score 1.958). I don't know how you'd account for the contribution from real roots, which x^6-2 has and 9x^6+1 lacks.

I'll willing to contribute to another collaborative effort, or to undertake one of the base 2 numbers suggested by R.D. Silverman. To do one of those solo I'd likely need a lot of help/advice as far as parameter selection, because I'm not experienced enough to be convinced I have it right otherwise. That said, comparing to 2,1598M (GNFS) to 6^383+1 and 2,799+ (SNFS) to 3,512+, I think I could do either in a little over a month (but might need help with the matrix).

Comments/advice?

[bdodson]

Originally Posted by fivemack

I wouldn't be very optimistic that sieving harder numbers will give the matrix queue a chance to clear, ...

The matrix for 3,536+ will be done within a week (pending no problems;
thanks for the reply on the msieve thread). So I want the next number
to take more than a week to sieve. The number 10,257+ at difficulty
257 was within a few hours of completely finishing sieving in under
seven days (although other users arrived, which added two days to
the walltime). The matrix for 10,257- is smaller/easier than 3,536+
despite being a harder number (due to oversieving). I do seem to have
disk space for four large matrices (barely) once 3,547- finishes sieving
later today; so 536+ will make space for 2,949+ and 257- will make space
for the one after that (both candidates having recently been c258's).

Your reply gives a long-term analysis for what we hope is a short-term
problem (pending my being able to ship a matrix or two off to Greg's
new machine, so we can alternate matrices and double the available
time for running harder numbers). We're mostly waiting for Greg's
C260 to finish to see where things stand. -Bruce

[bsquared]

I've done some trial sieving on 2,799+ with various parameterizations

Rational side sieving of this polynomial

 
n: 17046484339439502390787014663843382603841990311536588019427381788315112645544913528357093997566704677217496355462170676223202258500459624221675999642483043420478565738287873667689291
skew: 1 
c6: 2 
c0: 1 
Y1: -1 
Y0: 10889035741470030830827987437816582766592
rlim: 85000000 
alim: 75000000 
lpbr: 30 
lpba: 30 
mfbr: 60 
mfba: 60 
rlambda: 2.6 
alambda: 2.6

gave ~ 1.1 rels/q at 85M, and 0.6 rels/q at 185M, using gnfs-lasieve4I14e and test ranges of 1000 special-q. The area under the parallelogram is therefore about 85M rels (say 80M unique), which is in the vicinity of producing a matrix using the 0.8(pi(lpba) + pi(lpbr)) metric.

Algebraic side tests yielded less relations, and took longer, so rational side seems to be the way to go.

31 bit tests seemed to show that as many or more special-q would be needed, with the accompanying headaches of shuffling around twice as much data, so 30 bits seems to be the way to go.

I can probably sustain 3 to 5 million special-q per day, depending on cluster usage by others, so this would take anywhere from 20 to 40 days, depending on actual yield and resource availability.

*deep-breath*
I'll go ahead and reserve it. Other stuff in my queue will push the start out to next week sometime.

Suggestions/tweaks to parameters welcome.


- ben.

[R.D. Silverman]

Originally Posted by bsquared

I've done some trial sieving on 2,799+ with various parameterizations

Rational side sieving of this polynomial

 
n: 17046484339439502390787014663843382603841990311536588019427381788315112645544913528357093997566704677217496355462170676223202258500459624221675999642483043420478565738287873667689291
skew: 1 
c6: 2 
c0: 1 
Y1: -1 
Y0: 10889035741470030830827987437816582766592
rlim: 85000000 
alim: 75000000 
lpbr: 30 
lpba: 30 
mfbr: 60 
mfba: 60 
rlambda: 2.6 
alambda: 2.6

gave ~ 1.1 rels/q at 85M, and 0.6 rels/q at 185M, using gnfs-lasieve4I14e and test ranges of 1000 special-q. The area under the parallelogram is therefore about 85M rels (say 80M unique), which is in the vicinity of producing a matrix using the 0.8(pi(lpba) + pi(lpbr)) metric.

Algebraic side tests yielded less relations, and took longer, so rational side seems to be the way to go.

31 bit tests seemed to show that as many or more special-q would be needed, with the accompanying headaches of shuffling around twice as much data, so 30 bits seems to be the way to go.

I can probably sustain 3 to 5 million special-q per day, depending on cluster usage by others, so this would take anywhere from 20 to 40 days, depending on actual yield and resource availability.

*deep-breath*
I'll go ahead and reserve it. Other stuff in my queue will push the start out to next week sometime.

Suggestions/tweaks to parameters welcome.


- ben.

Actually since the exponent is divisible by 17 we could, in theory save a
factor of 2^47 (i.e. it becomes 752 bits), but we would have to work with a
reciprocal octic polynomial....... Which is quite sub-optimal.

But it would be an interesting experiment.....

[xilman]

Originally Posted by bsquared

gave ~ 1.1 rels/q at 85M, and 0.6 rels/q at 185M, using gnfs-lasieve4I14e and test ranges of 1000 special-q. The area under the parallelogram is therefore about 85M rels (say 80M unique), which is in the vicinity of producing a matrix using the 0.8(pi(lpba) + pi(lpbr)) metric.

I agree that these parameters are reasonable and that you'll probably need about 76-80M unique relations.

I doubt, however, that the duplication rate will be 6%, the value of (85-80)/85, but is rather more likely to be 20-25%. At least, that's been my experience with numerous lattice sievers in the past.

I would assume 90-100M raw relations will be required. You may be pleasantly surprised in the end but setting expectations to realistic values before a large computation is almost always a good thing, IMO.


Paul

[bsquared]

Originally Posted by R.D. Silverman

Actually since the exponent is divisible by 17 we could, in theory save a
factor of 2^47 (i.e. it becomes 752 bits), but we would have to work with a
reciprocal octic polynomial....... Which is quite sub-optimal.

But it would be an interesting experiment.....

I had not considered octic polynomials... can msieve deal with them? Or the ggnfs postprocessing suite? I don't have any other tools at my disposal for postprocessing.