[QUOTE=fivemack;190126] I think to some extent they're intended as a gentle introduction for the NFS methods[/QUOTE]

Actually, I started these tables not as an [b]introduction[/b] to NFS,
(although it somewhat serves that purpose now)
but as a source of relatively easy numbers that I could use to test
changes/algorithmic improvements in my existing code. I wanted
numbers that I could do in a couple of days, as opposed to a couple of
months.

[QUOTE=R.D. Silverman;190202]Actually, I started these tables not as an [b]introduction[/b] to NFS,
(although it somewhat serves that purpose now)
but as a source of relatively easy numbers that I could use to test
changes/algorithmic improvements in my existing code. I wanted
numbers that I could do in a couple of days, as opposed to a couple of
months.[/QUOTE]
I really must stop factoring these for a while. It has become an obsession for me - I believe I'm so sensitive to my own endocrine system that I get the same endocrine rush from seeing a p52 pop out (via ECM or SNFS) that a gambling addict gets from that row of cherries on the slot machine.

Just a couple more. I can quit any time I want to.

BTW, the bottom half of the eligible numbers are now mostly quartics or sextics, seeing as so many exponents are multiples of 3 or 5. Easy, sure, but not the push-overs which used to populate that page. An SNFS 165 will now actually prove a little vexing. :evil:

9^220 + 7^220, C104:

[CODE]
***factors found***
PRP66 = 888399114863220054416373993221092999905502700297301957333000997481
PRP39 = 211523074369177100475152901773214226961
[/CODE]

2.5 hrs using yafu with 8 threads.

[code]
[2009-09-15 16:45:41 GMT] a: Factor found! 9+2_260 / (probable) 28690664225908528276213787906580887441 B1: 3000000 sigma: 2991532843 (found in step 2)
[2009-09-15 16:45:41 GMT] a: Co-factor: 9+2_260 / (Probable) 14587998392173964904787371399139290217123654303673351458474015780256506282177198145887068358520476133056001

[2009-09-24 15:23:37 GMT] a: Factor found! 3+2_509 / (probable) 215218400405502755118512937380964072656140046143 B1: 3000000 sigma: 2314041384 (found in step 2)
[2009-09-24 15:23:37 GMT] a: Co-factor: 3+2_509 / (Composite) 799220843412351101694407312078080122397617515762852395064316035582154800750358786611217214878222184353764850244311388757587168694883595813353156831188909211856009

[2009-09-14 16:58:06 GMT] a: Factor found! 10-9_205 / (probable) 10538083078679938485488932422049608961 B1: 3000000 sigma: 2371305371 (found in step 2)
[2009-09-14 16:58:06 GMT] a: Co-factor: 10-9_205 / (Probable) 3318662517297367161673105208663479146310289311414979560534669095138681006986134088840636053114511431


[/code]

6^305-5^305
c187=p86*p101
p86=61354086166327175506135010593104815799650445717069705996004110781733273331468560314151

8^237+5^237, SNFS:

prp47 factor: 40909542570823085894050006456260554783987683201
prp61 factor: 6572806048861503063369633806850020012932458743034736686826477

2^515+3^515
c195=p46*p150
prp46 factor: 6323936008157830475003364666645683920069827121

Not an ECM-miss, but 6000 curves @ B1=11e6 were done before SNFS.
Sieving takes 80cpu-days with 14e siever. I don't know, why it has occupied so a lot of time (can be because quartic?).

Help with SNFS polynomial selection
 

It seems that I'm still in the dark as to how to choose appropriate polynomials for factoring these numbers via SNFS. Can anybody help to enlighten me? As a test for myself, I tried 8+7,243. I generated what I thought were the obvious polynomials, to wit:

x^6 - x^3 + 1 and
7^27x - 8^27

with m = (8/7)^27.

Then I used ggnfs and msieve (via the factMsieve.pl script) to factor the number. According to the script, the factorization had an SNFS difficulty of 146.3, which agrees with how it appeared on Tom Womack's reservation page, so I assume those polynomials are at least plausibly correct.

The factorization completed without incident, but it took longer than a previous factorization I had done of a C111 via GNFS. That seems way too long, since this composite was only 109 digits and I could have factored it via GNFS more quickly.

So what was the problem? Is a 6th degree polynomial just inappropriate for a number of this size? Or am I doing something stupid?

[quote=jyb;192616]So what was the problem? Is a 6th degree polynomial just inappropriate for a number of this size? Or am I doing something stupid?[/quote]
A sixth degree polynomial isn't optimal for that size snfs although it can still end up being the best method.
That might even be degree 4 territory.
That number is reasonably close to the gnfs/snfs border i think. If you add in the fact that the best snfs polynomial is degree 6(might be already included in the difficulty) it might be worthwhile using gnfs.

Can someone with more experience confirm what i have said please?

Degree 6 is highly suboptimal for SNFS here; normally SNFS problems have to get to ~190 digits before it's faster to use degree 6 polynomials.

...when there's a choice 5th/6th-degree, then the crossover is about 190 digits, yes. But if the choices are 4th/6th, then the crossover is about 160 digits, I think. And if you use the 6th degree, use -a sieving (add [B]lss: 0[/B] to the .poly file).