Fast Breeding (guru management)

[swellman]

QUEUED C226_131_92 is ready for sieving on 15e.

n: 2594357408754528840336959976776254616275246107866122821999046266053766159058030850231097893328128352328947096832750386386130266785143101133671784697182867503271185161380822889883416013987993463560795091939357749857883574352801
# 131^92+92^131, difficulty: 259.22, anorm: 2.51e+039, rnorm: 4.86e+048
# scaled difficulty: 260.77, suggest sieving rational side
# size = 2.575e-013, alpha = 0.857, combined = 4.514e-014, rroots = 0
type: snfs
size: 259
skew: 10.7908
c6: 1
c0: 1578812
Y1: -57420825906681085498936641961451
Y0: 15971003380339100300054651735509963965988864
rlim: 268000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 64
rlambda: 2.8
alambda: 2.8

Test sieving on the -r side with Q in blocks of 5K:

Q=20M    13089
Q=80M    10527
Q=150M    9353
Q=250M    8299

Suggesting a sieving range for Q of 20M-245M with a target number of relations = 450M.

[RichD]

QUEUED C216 from the OPN t800 file.
[ a.k.a. Phi_5(Phi_5(Phi_29(11)/523)/1811/10492129345935944590511/120083120723324592094962551)/5/251 ]
P55^5-1

n: 150826953004613608413756734306900070962473810747766544031798084407009355892093285604292852673042954908898374690039074473850084340841788948543178619587650159533492100551160336211807530026414470114592791019534905979311
# 3709203584816762750361605901613244632119234246512357131^5-1, difficulty: 218.28, skewness: 1.00, alpha: 1.45
# cost: 6.67255e+17, est. time: 317.74 GHz days (not accurate yet!)
skew: 1.000
c4: 1
c3: 1
c2: 1
c1: 1
c0: 1
Y1: -1
Y0: 3709203584816762750361605901613244632119234246512357131
type: snfs
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 92
mfba: 62
rlambda: 3.6
alambda: 2.6

Trial sieving 5K blocks.

  Q  Yield
 20M  9635
 60M 10910
100M 11097
150M 10415

[fivemack]

I am surprised that C182_134_107 is not being done as a GNFS number - the yields look pretty low for SNFS, and combined = 1.470e-014 compares poorly to the 'expecting poly E from 5.46e-14 to > 6.27e-14' from msieve.

[swellman]

It was a close thing, and I originally had it down as a GNFS. But considering poly search time, and the fact that SNFS isn’t ridiculously difficult swayed me.

[VBCurtis]

Originally Posted by swellman

QUEUED C182_134_107 is ready for SNFS on 15e. All combinations of 3LP were not productive.
Suggesting a sieving range for Q of 20M-530M with a target number of relations = 460M.

Would GNFS-182 be faster? I'm too lazy to feed this SNFS poly into msieve to see how it compares with the GNFS-183 record, but 20-530MQ sounds way tougher than GNFS.

[swellman]

See above. I also considered estimated time to sieve, which appeared to be much closer than the respective e-scores would indicate.

If it seems too much effort, we can pull it out of queue and I’ll submit it as a GNFS job later.

[VBCurtis]

Whoops for not noticing the "next page" active button! Sorry for duplicate posts.

[swellman]

Originally Posted by fivemack

I am surprised that C182_134_107 is not being done as a GNFS number - the yields look pretty low for SNFS, and combined = 1.470e-014 compares poorly to the 'expecting poly E from 5.46e-14 to > 6.27e-14' from msieve.

One last point that makes me pause is the fact one cannot directly compare e-scores between polys of different degree. In the case of C182_134_107, SNFS is a sextic and GNFS a quintic. So I tend to compare sieving times. For GNFS, I built a model using record e-scores vs estimated time to sieve on my machine. This tells me for a given GNFS difficulty (assuming a vigorous poly search) the estimated time to sieve.

Or am I making this harder than it needs to be?

In the case of C182_134_107, the estimated time to sieve using SNFS likely has grown from original estimates.

[VBCurtis]

When comparing different degrees, I wouldn't claim a 50% difference in score is proof that one is better than the other, but we're talking a factor of 3 or 4 here; I'd wager GNFS is faster by at least 33% (that is, would take 75% of the computation that SNFS would take), and I won't be surprised if it's twice as fast (50% effort).

[RichD]

QUEUED AS C223_152407_43 BECAUSE I CAN'T READ
C218 from the OPN t550 file.

n: 48552238369764222404451202815863870784923640485950052568134184776529275037262960949926252818354286473949118268321922244437788062275291574704623632133947396586935180950344112960928573499107977576583231784028003649602057
# 152407^43-1, difficulty: 223
skew: 0.137
c6: 152407
c0: -1
Y1: -1
Y0: 1910004547189193227289967055663496743
type: snfs
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6

Trial sieving 5K blocks.

  Q  Yield
 20M 10384
 50M  8000
 80M  6279
110M  6362

[swellman]

Originally Posted by VBCurtis

When comparing different degrees, I wouldn't claim a 50% difference in score is proof that one is better than the other, but we're talking a factor of 3 or 4 here; I'd wager GNFS is faster by at least 33% (that is, would take 75% of the computation that SNFS would take), and I won't be surprised if it's twice as fast (50% effort).

Surprisingly the difference was <15%, in favor of GNFS, plus poly search time. But when I fully characterized the SNFS poly in preparation for sieving, I ultimately increased it to a 32-bit job, resulting a bit slower sieving (though with better yield). So it’s current state, GNFS is about 19% faster than SNFS. On my machine, 161 weeks to sieve GNFS vs 190 weeks to sieve via SNFS. (It was closer with 31-bit.) I should have circled back to check the final sieving time estimates. Guess I was anxious to feed the grid.

I’ve got a similar upcoming composite, namely C184_137_92. A G184 is ~S277 in difficulty, and I’ve identified a SNFS poly that is 271 in difficulty. So it’s SNFS, right? But sieving time estimates show GNFS is 203 weeks versus 224 weeks to sieve via SNFS. I’m just hoping ECM splits it first!

I say pull C182_134_107 and I will post it as a GNFS sometime in the future. But please know that I spent a lot of time vacillating between G and SNFS!