Fast Breeding (guru management)

[jyb]

Originally Posted by RichD

These are the default parameters out of factMsieve and then changing to 14e and lpb=31/62. Most likely not optimal.

n: 620595445212886197477191763266087920164778283551144144831883282223415660307863206244244816417687295355308926397314396118416074156134623096759384176319664870366271916273988877636289052746091391
m: 494124614835927587916699085265816641
c6: 790579404481
c5: 0
c4: 0
c3: 0
c2: 0
c1: 0
c0: -1
Y1: -1
Y0: 494124614835927587916699085265816641
skew: 96.16
rlim: 25450000
alim: 49700000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.6
alambda: 2.6

P.S Off the top of my head, before trial sieving, I would have guessed deg-6 would have been better because you are not elevating the difficulty by the large base.

Your skew is wrong. It needs to be the reciprocal of what it is, so 0.0104.

[RichD]

Originally Posted by jyb

Your skew is wrong. It needs to be the reciprocal of what it is, so 0.0104.

I thought I saw a post by RDS which states the skew can be calculated either way (c0/c6)^(1/6) or (c6/c0)^(1/6). Technically, you can reverse the expression to -1+P^19 to get the same results. After RDS post, I tried it on a single test case and it didn’t seem to make a difference so I assumed it worked for all cases. I always use a skew => 1 mostly for readability.

[jyb]

Originally Posted by RichD

I thought I saw a post by RDS which states the skew can be calculated either way (c0/c6)^(1/6) or (c6/c0)^(1/6). Technically, you can reverse the expression to -1+P^19 to get the same results. After RDS post, I tried it on a single test case and it didn’t seem to make a difference so I assumed it worked for all cases. I always use a skew => 1 mostly for readability.

I don't know the ins and outs of how the skew value works. What I can tell you is that with no other differences, a skew of 0.01 gave me a yield of 1766, while a skew of 96.16 gave me a yield of 168. Doesn't sound interchangeable to me.

And yes, you can reverse the expression and thereby reverse the coefficients of the algebraic polynomial, but then you would have to also reverse the coefficients of the rational polynomial as well. So yes, you could have a polynomial of x^6 - P instead of P*x^6 - 1, so your skew would be 96.16. But then you would also need the rational polynomial to be P*x - 1, instead of x - P. And if you do that, you will find that you get the good yield. Perhaps that was what RDS meant. But it is empirically not the case that you can take given algebraic and rational polynomials and just invert the skew with no other changes and have the same result.

[unconnected]

C158 from 11040:i9973, hope it's not too small to queue.

# norm 2.522525e-15 alpha -7.948414 e 1.735e-12 rroots 5
n: 94365299263068962988012065760895517846470483814873149655656138236616822393971530881311607016496429678973685304173579262984938116954010188591484289720399078137
skew: 6464797.84
c0: 675785156710726931995945512743568655440
c1: 572425050798434972990547357805552
c2: -422264771447737172677419726
c3: -28003604281125954411
c4: 10201446613954
c5: 292152
Y0: -3175708354283273613785639237497
Y1: 83795508091313227
rlim: 36800000
alim: 36800000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
lss: 0

[RichD]

Originally Posted by jyb

So yes, you could have a polynomial of x^6 - P instead of P*x^6 - 1, so your skew would be 96.16.

I think you are referring to the differences between degree 5 and 6 here.

That gave me an idea to multiple the polynomial by -1 and try that.

[swellman]

Originally Posted by fivemack

C192_139_81 queued up on 15e

It's a moderately large job - yield is ~1 at Q=2^28 so I've queued up half a billion Q, Murphy score for the SNFS polynomial is 1.875e-14, I suspect it'll take three weeks on a six-core machine for the linear algebra.

To compare, C277_150_122 has Murphy 1.811e-14, and the very hard C272_136_105 had 6.387e-15; I think the Murphy scores are usually more predictive of post-processing difficulty than the SNFS size.

Due to a mixup somewhere (possibly here), Ryan Propper has already begun (and nearly finished) NFS of C192_139_81. Please remove it from the queue. Not sure how this happened.

[RichD]

Thanks to some guidance by Jon and more trial sieving (still using the poorly picked a/rlim values so as to compare apples), I have a few more data points. The reason for spending more time on this is because there are a few more P^23-1, P^31-1 and a P29^-1 downstream - if they make it to NFS@Home.

The below yield using 5K blocks, lpb=31/62 and skew=96.16 with the 14e siever.

special-Q =>  30M    80M   130M   180M
-r           5397   3100   2776   2202
-a           5063   4148   3227   2683

It makes no difference whether the poly was multiplied by -1 as long as the skew is in alignment.

c6: 1
c0: -790579404481
Y0: -1
Y1: 494124614835927587916699085265816641

or

c6: -1
c0: 790579404481
Y0: 494124614835927587916699085265816641
Y1: -1

[jyb]

Originally Posted by RichD

I think you are referring to the differences between degree 5 and 6 here.

That gave me an idea to multiple the polynomial by -1 and try that.

Sorry, I don't understand what you mean here. I was definitely not talking about the differences between degree 5 and degree 6 polynomials. I was talking only about degree 6 polynomials, and what it means to "reverse the expression."

As for multiplying by -1, I expect you'll find it has no effect at all.

Originally Posted by RichD

Thanks to some guidance by Jon and more trial sieving (still using the poorly picked a/rlim values so as to compare apples), I have a few more data points. The reason for spending more time on this is because there are a few more P^23-1, P^31-1 and a P29^-1 downstream - if they make it to NFS@Home.

The below yield using 5K blocks, lpb=31/62 and skew=96.16 with the 14e siever.

special-Q =>  30M    80M   130M   180M
-r           5397   3100   2776   2202
-a           5063   4148   3227   2683

It makes no difference whether the poly was multiplied by -1 as long as the skew is in alignment.

Yes, that's what I'd expect, if by "alignment" you mean that the skew is equal to |c0/c{d}|^(1/d) rather than the reciprocal of that.

Originally Posted by RichD

c6: 1
c0: -790579404481
Y0: -1
Y1: 494124614835927587916699085265816641

or

c6: -1
c0: 790579404481
Y0: 494124614835927587916699085265816641
Y1: -1

The second of these won't work at all because you've reversed Y0 and Y1. But assuming that was basically just a typo, then yes that looks right.

[jyb]

Originally Posted by unconnected

C158 from 11040:i9973, hope it's not too small to queue

Can't really afford to turn numbers away at this point. Queued.

[swellman]

C216_121_113

n: 184094249934242069109125400577734390742548104719895085120467810751106288077867672040540076314269050554956696743669861492086142981324147214138504059557436906452399425489524304775399446108214150636093601470375888591597
# 121^113+113^121, difficulty: 248.42, anorm: 2.34e+038, rnorm: -2.53e+047
# scaled difficulty: 249.93, suggest sieving rational side
# size = 1.745e-012, alpha = 0.000, combined = 1.801e-013, rroots = 0
type: snfs
size: 248
skew: 4.8900
c6: 1
c0: 13673
Y1: -115230877647233745723406127208308085892801
Y0: 3740434344477351388916475705363381856681
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7

[chris2be8]

Originally Posted by RichD

It makes no difference whether the poly was multiplied by -1 as long as the skew is in alignment.

c6: 1
c0: -790579404481
Y0: -1
Y1: 494124614835927587916699085265816641

or

c6: -1
c0: 790579404481
Y0: 494124614835927587916699085265816641
Y1: -1

In the second poly msieve will probably object to the leading coefficient being negative when you get to the square root stage. I hit this once and managed to fix it by reversing the signs of all the coefficients and re-running msieve -nc3. But I would not rely on that working.

Chris