I'll check out 1276649964690308261^11-1 and 91403581555155409^13-1.

I don't have a great deal of experience with SNFS, so could someone please confirm that these are the correct polynomials for these numbers, or otherwise suggest alternatives.

1276649964690308261^11-1
[CODE]n: c165 (as it is partially factored)
deg: 5
type: snfs
c5: 1
c4: 1
c3: -4
c2: -3
c1: 3
c0: 1
Y1: 1276649964690308261
Y0: -1629835132343765329585630703204844122
skew: 1[/CODE]

91403581555155409^13-1
[CODE]n: c169 (as it is partially factored)
deg: 6
type: snfs
c6: 1
c5: 1
c4: -5
c3: -4
c2: 6
c1: 3
c0: -1
Y1: 91403581555155409
Y0: -8354614721109946096436786141957282
skew: 1[/CODE]

I also don't know how to craft a polynomial for the P46^5-1 numbers without getting completely unreasonable coefficients, so is there any information surrounding those?

Yep, they look good.

P46^5-1 is straight forward. (P^5-1)/(P-1) = x^4 = x^3 + x^2 + x + 1 or
[CODE]c4: 1
c3: 1
c2: 1
c1: 1
c0: 1
Y1: -1
Y0: <P>
skew: 1[/CODE]
Likewise for P^7-1 but it is a sextic.

The remaining composite part of 1276649964690308261^11-1 has been factored into:
[CODE]r1=43307026303766305007772552713502191243822687402841405758867621914554801961594297 (pp80)
r2=11906098275515825037146010052048707833460769373575909135601964454504741403053226488103 (pp86)[/CODE]

Despite the similar size of the numbers to be factored, the run times are quite different. For this p^11-1 sieving took 8 hours (to 138% of the expected minimum relations), and the matrix solve another 1. While in the same time, on a faster computer, the sieve for the p^13-1 is only at 17.5%.

Anyway, I will also upload these factors to factordb and check out:
2466739853447356693784400912569671699278008503^5-1

The time for sieving is more closely related to the SNFS difficulty than the size of the remaining composite.
A quick estimate for these groups would be the expanded size minus the size of P (in digits).
Your first number P^11-1 is 200-19 or SNFS-181.
The second number P^13-1 is 221-17 or SNFS-204.

I'll try to post the average SNFS difficulty for each group going forward.
That said, the current groups are:
P46^5-1 = around SNFS-181.
P30^7-1 = around SNFS-178.
P19^11-1 = around SNFS-185.
P17^13-1 = around SNFS-198.
The lonely P16^13-1 is SNFS-180.

I understand that if a "special" number has known factors that are large enough, then it can become faster to run GNFS on the remainder instead, but assuming that is not the case is there any benefit to dividing out the known non-algebraic factors for these numbers?

[QUOTE=lavalamp;449638]I understand that if a "special" number has known factors that are large enough, then it can become faster to run GNFS on the remainder instead, but assuming that is not the case is there any benefit to dividing out the known non-algebraic factors for these numbers?[/QUOTE]

Everything you said is correct. Not sure what you are getting out in the last comment.

There is not a way to reduce the SNFS polynomial by dividing out the known non-algebraic factors. The N would be a little smaller so maybe there would be a savings of 1% in the relation calculations and collection.

To find the smaller factors first (via ECM) is sometimes beneficial because it is unknown whether the remaining number [strike]in[/strike] is composite or prime. If prime, game over!

[QUOTE=lavalamp;449638]I understand that if a "special" number has known factors that are large enough, then it can become faster to run GNFS on the remainder instead, but assuming that is not the case is there any benefit to dividing out the known non-algebraic factors for these numbers?[/QUOTE]

Aside from the possible 1% or less arithmetic gains, the primary benefit is so that the NFS program (yafu/msieve/factmsieve etc) know when to stop the sqrt -- otherwise if they find one of the smaller known factors first, they'll stop immediately assuming that the number is FF even if the unknown part wasn't handled. (Such a case can be immediately fixed by resuming the sqrt stage with a different dependency.) (And yes, I think it's a bit silly that msieve doesn't do an extremely cheap prp test on the resulting cofactor and continue if that fails, but hey, it's no big deal.)

[QUOTE=Dubslow;449646]Aside from the possible 1% or less arithmetic gains, the primary benefit is so that the NFS program (yafu/msieve/factmsieve etc) know when to stop the sqrt -- otherwise if they find one of the smaller known factors first, they'll stop immediately assuming that the number is FF even if the unknown part wasn't handled. (Such a case can be immediately fixed by resuming the sqrt stage with a different dependency.) (And yes, I think it's a bit silly that msieve doesn't do an extremely cheap prp test on the resulting cofactor and continue if that fails, but hey, it's no big deal.)[/QUOTE]

Huh? Msieve [I]does[/I] do a prp test on the cofactor. Actually, with recent versions it does a full APRCL primality test on the cofactor. With the exception of a bug described [URL="http://mersenneforum.org/showpost.php?p=408761&postcount=75"]here[/URL], msieve always continues the square root phase until the number is fully factored.

[QUOTE=jyb;449674]Huh? Msieve [I]does[/I] do a prp test on the cofactor. Actually, with recent versions it does a full APRCL primality test on the cofactor. With the exception of a bug described [URL="http://mersenneforum.org/showpost.php?p=408761&postcount=75"]here[/URL], msieve always continues the square root phase until the number is fully factored.[/QUOTE]

Hmm... maybe I'm thinking solely of yafu then. I'll admit my non-yafu usage is basically nil.

[QUOTE=Dubslow;449679]Hmm... maybe I'm thinking solely of yafu then. I'll admit my non-yafu usage is basically nil.[/QUOTE]

My yafu usage is exactly nil, but I was under the impression that it used msieve for NFS. Is that not correct?

If msieve is running square roots for a number with more that two factors it will have to run at least two successful square root steps. So not dividing out factors found by ECM will increase the number of square roots that need to be run. This isn't usually a big delay but worth avoiding.

Chris