Factoring for a publication

[bur]

So it seems I should have taken the time to convert everything to msieve...

I had that problem with "no suitable prime" before, I think I used msieve and as you said, it worked. Going from cado *.gz files to msieve rels.dat is actually not that much of a problem using zcat, took some minutes for a 220M rels job. I usually have a script for factoring GNFS numbers that does sieving in cado and LA in msieve as msieve is apparently faster and more robust (as evident) for that step.

So I can do the LA in msieve if cado fails, are you generally interested in the relations anyway? It's 22891 *.gz files, I can zip and upload them tomorrow.

[Max0526]

Originally Posted by bur

I'd still like to see this run with the alternative parameters. Or with alternative poly.

The relations are 3.8 GB in gzip'ed form. If you're interested in them, I could upload them somewhere.

The only two better spun polys are:

n: 763374743763081217914694138634486780344024237091539368674972788624046972741046710708718787293421106975357383724033172253608940141301420411687874833865804305796864727

Line 5 : {'c4': '1', 'c3': '0', 'c2': '8', 'c1': '-12', 'c0': '7', 'y1': '1419008023915103851777842927951067360939048893550', 'y0': '27465776209625260799657682734475139886128029362001'}
Skew, Murphy E:
3.0883 3.76142443e-12

Line 76 : {'c4': '4', 'c3': '8', 'c2': '14', 'c1': '4', 'c0': '1', 'y1': '28884784233540364651435525662426207247067078255551', 'y0': '1419008023915103851777842927951067360939048893550'}
Skew, Murphy E:
0.31637 3.72885133e-12

I will re-post the full polys later too, another opportunity to test the version 2 of swishzzz's Python script.

[bur]

It's getting funny. Cado failed at square root as expected. And msieve then decided it's too few relations to build a matrix and requested 1,000,000 more. For good measure I now have cado sieve 2M additional relations and then tomorrow morning I'll attempt to use msieve again.

Is it due to differences in taget density that msieve fails?


At least one thing can't go wrong, A4 is a positve integer. I think msieve doesn't like a negative first coefficient. But who knows what'll happen next?! :D

[bsquared]

Originally Posted by bsquared

Advancing to t40 on unreserved composites on lines 158,160,163, and 167-172

Progress:

(10,-7)
c256 = p38*c219

(5,-10)
c157 = p36*p50*p73

Now done: all ecm'ed to t40 with 1 partial and 1 complete factorization.

This post was probably not being monitored any longer... t40 is done with the above results.

[bsquared]

Test sieving the two difficulty 221 polys for the c198 on line 128. yafu spits out the following parameters (poly 2 is very similar):

n: 442480456268307355970377486465969784979730470279409306982158698829691328120816007497057176155135483213248563103903861494465722951888948657031409779919681670455655411204200835023769409621132838744169
# e = 2.41372557e-13
type: snfs
skew: 1.16292
size: 221
c4: 1
c3: 0
c2: 2
c1: -12
c0: 10
Y1: 3105317578628153423506739578983437982692791417722955507
Y0: 1783785732675759131389551214804762300612349559114245473

rlim: 47442301
alim: 32751539
lpbr: 31
lpba: 29
mfbr: 89
mfba: 58
rlambda: 3.6
alambda: 2.6

Test sieving with 14e gives just barely over 1 rel/q over a range of q in the factor base, trailing off to < 0.9 rel/q when out of the factor base. Looks like it should be a 15e job.

poly 1 total yield: 4120, q=24004021 (0.13340 sec/rel)
vs. 
poly 2 total yield: 4209, q=24004021 (0.13017 sec/rel)


poly 1 total yield: 4250, q=32004043 (0.13677 sec/rel)
vs.
poly 2 total yield: 4258, q=32004043 (0.13573 sec/rel)


poly 1 total yield: 4222, q=40004011 (0.14301 sec/rel)
vs.
poly 2 total yield: 4174, q=40004011 (0.14686 sec/rel)


poly 1 total yield: 3597, q=80004013 (0.15816 sec/rel)
vs.
poly 2 total yield: 3584, q=80004013 (0.15315 sec/rel)

The test results seem too close to call, so I guess I'll go with the better E-score. Would anyone want to weigh in on the chosen parameters?

[RichD]

Originally Posted by bsquared

Would anyone want to weigh in on the chosen parameters?

What side are you sieving, -r? rlim seems awfully low, like a factor of three. What would, say, rlim at 134M yield?

[bsquared]

Originally Posted by RichD

What side are you sieving, -r? rlim seems awfully low, like a factor of three. What would, say, rlim at 134M yield?

Yes, -r. I had thought the same, so I started a test with rlim=127M shortly after posting. I get:
total yield: 3958, q=80004013 (0.17637 sec/rel)

So the yield goes up 10% or so at larger Q ranges at about the same cost to sec/rel. If using 14e then I think it makes sense to maintain higher yields over the 120MQ range I'd probably need to sieve. If using 15e then I think a smaller rlim will have less of an impact. I should probably test sieve it.

[charybdis]

Originally Posted by bsquared

The test results seem too close to call, so I guess I'll go with the better E-score. Would anyone want to weigh in on the chosen parameters?

NFS@home has run quartics of similar difficulty as 31-bit jobs, so it might be worth bumping the lpbs up by 1 and increasing mfb/lim correspondingly.

[bsquared]

Originally Posted by charybdis

NFS@home has run quartics of similar difficulty as 31-bit jobs, so it might be worth bumping the lpbs up by 1 and increasing mfb/lim correspondingly.

Do you mean bump it up to 32/30? It is already 31/29, with 3LP on the rational side.

[charybdis]

Originally Posted by bsquared

Do you mean bump it up to 32/30? It is already 31/29, with 3LP on the rational side.

Yes. The relevant NFS@home jobs were run as 31/31 but would likely have been faster as 32/30.

[Max0526]

Originally Posted by bsquared

This post was probably not being monitored any longer... t40 is done with the above results.

Thank you, bsquared, for bringing it up!
It was sandwiched in between two swishzzz's stage 12 posts and I missed it last night.
Updated now.