I will finish up the last three P30^7-1 this weekend. The next group is:
P31^7-1 ~SNFS-[strike]153[/strike]184
[CODE]2121379629902041750864180018843^7-1
6924478858931407658578569945691^7-1
6650957363165339695936905289261^7-1
2859286042629423856173710917681^7-1
1018931726790243197488050343793^7-1
4825271821914057314662245548779^7-1[/CODE]
Yes, I miscalculated the difficulty for exponents 5 & 7 last time.

Edit: My mistake again. It was originally correct.

(p46^5 - 1)/(p46-1) factored:
[url]http://www.factordb.com/index.php?query=2466739853447356693784400912569671699278008503%5E5-1[/url]

Despite having the same SNFS difficulty 182 as the previous (p19^11-1)/(p19-1) number, it took over 5 times longer to sieve, and nearly twice as long for the matrix solve time.

I've now started another number with SNFS difficulty only 169, which based on current observations will take at least twice as long again.

Starting to get the sense that this SNFS difficulty should be taken with a very large grain of salt.

There are a few more variables at play here. I can’t give quantitative answers (maybe others can) but a few rule of thumb examples.

Degree halving does buy some savings. For example the traditional poly for P^11-1 would be P*(P^2)^5-1. Degree halving reduces the difficulty by one power effectively making it an SNFS-sizeof(P^10). Likewise on powers of 5 & 7, they get reduced.

In this size range a quintic is optimal. So there is a penalty for using a quartic or sextic. For, say, an SNFS-130 a quartic would be the best. Therefore a P^5-1 would perform better than a sextic P^13-1. As the numbers (difficulties) get larger the P^13-1 & P^7-1 would perform better, relatively speaking. Say above SNFS-220.

Why not run a P^5-1 as a quintic if it is optimal in this range? It is much better to reduce the difficulty level than incur the penalty. The P46^5-1 would increase about 46 in difficulty. With running time doubling every nine digits (SNFS) there are a lot of nines in 46.

Other comments welcome.

[QUOTE=RichD;449760]Why not run a P^5-1 as a quintic if it is optimal in this range?[/QUOTE]
You can't use a reducible polynomial. First, the siever will complain a lot (its internal buffers will overflow, and when this is the case, it will skip all q0 values where buffer overrun happens; so its visible output will be miniscule, even if/when the complains are disabled*). Second, there may be problems later in the pipeline (afair, in sqrt stage in particular).
___________
*I think most binaries people use have the error messages disabled.

[QUOTE=RichD;449760]In this size range a quintic is optimal. So there is a penalty for using a quartic or sextic.[/QUOTE]Is there a rule of thumb for the relative costs of using a quartic, quintic, sextic etc?

I have just started work on (34179328063^17-1)/(34179328063-1) from here: [url]http://oddperfect.org/composites.html[/url]

I tried degree 4, 5, 6 and 8 polynomials, as well as a degree 5 from sieving, and the degree 8 won out. ALL of them were far slower to sieve than I would have expected. I guess the main reason my degree 8 poly was faster is because it is SNFS difficulty 169, where the next closest one (deg 4) was SNFS 180.

Although I do have an additional question about the degree 5 polynomial in particular. When I tried to sieve with this, instead of reporting the usual <number> sec/rel reported on the command line, I had something like "#INFO sec/rel". Is this some bug in factmsieve.py perhaps? I've attached all my test poly files (renamed with .txt) if someone wants to take a look.

Edit: D'oh, just realised I messed up the skew on my deg 5 and 6 polynomials. I don't have a spare machine to test on at the moment, so does anyone know if a skew of 57 would make the degree 6 polynomial competitive with the degree 4 and 8 ones?

I don’t have much time to reply but just a quick note before I leave for the evening.

For some reason SNFS works better with small coefficients, like 4 or 5 digit max. After that it gets a little squirrelly. I don’t know if it is because of the large coefficient or the high skew value. The project XYYXF could potentially have large coefficients but I don’t follow them too close. Then again, it would be the first and last coefficients that are large and could cancel out to create a reasonable (whatever that is) SNFS skew value.

[QUOTE=jyb;449685]My yafu usage is exactly nil, but I was under the impression that it used msieve for NFS. Is that not correct?[/QUOTE]

It does, but the details about whether msieve or yafu checks the cofactor might differ. I'm not really sure, nor do I honestly particularly care :smile:

[QUOTE=jyb;449685]My yafu usage is exactly nil, but I was under the impression that it used msieve for NFS. Is that not correct?[/QUOTE]
Yes, but is "linked-in", i.e. "msieve at the time when yafu was built", plus "b2's possible improvements". It does not call msieve, the same way as it calls gmp-ecm and ggnfs packages (i.e. you do not need msieve copy/installation to run yafu, but you do need ecm and nfs tools if you want to factor faster).

Factored 91403581555155409^13-1 into p68 and p101, uploaded to factordb.com

I'll check out 1849863004983048103^11-1 now.

[QUOTE=lavalamp;449763]I have just started work on (34179328063^17-1)/(34179328063-1) from here: [URL]http://oddperfect.org/composites.html[/URL]
[/QUOTE]

A better GNFS poly for c157. Found by CADO-NFS.
[code]Msieve v. 1.52 (SVN 958)
R0: -2604247635258189852253503999349
R1: 11300080801866688931
A0: -223195343074840795960124860995574003440
A1: 17517313976223771517952489177844
A2: 1481010019020335262191910
A3: -3994837325315792372
A4: 82445751743
A5: 8940
skew 11662420.13, size 3.306e-015, alpha -6.461, combined = 2.317e-012[/code]

Remaining composite part of 1849863004983048103^11-1 was split into p79 * p84.

I quite like these 11's, they're fast. :P

I'll checkout these 4 others:
3191686493279737051^11-1
9224843685451579741^11-1
5674020528076214323^11-1
9914944534833970091^11-1