Maybe flip rlim and alim? The rational norms will probably be larger for this input...

[QUOTE=jasonp;232626]Maybe flip rlim and alim? The rational norms will probably be larger for this input...[/QUOTE]

Considering that too large an FB is more benign than too small, I'd suggest to bump both of them to 2^24-1. And probably start sieving from lower special-q (say 3 mil?). Siever 13e or 14e -- at this size, it's probably a wash.

The alim of 8000000 was because factMsieve.pl lowers alim to the start of the range it is sieving from.

I've restarted with alim and rlim just under 2^24 from q0: 3e6 and I'm getting a better yield even though alim gets lowered to 3e6. Hopefully the yield will rise further as alim rises.

The numbers with exponent 16 seem the hardest to handle. I'm almost wondering what an inverted octic would yield (at a guess even worse though). But I don't plan to try it, I'm more limited by human time than CPU time.

Thanks for the advice though!

Chris K

A result from my other system doing SNFS:
sigma(15428908531^16)
r1=14626378603026637440876935345110752326808617649740543443295899 (pp62)
r2=348735520870862164578134010988731594775521012539225570516087953133011785002062963 (pp81)

And two more ECM results:
[code]sigma(141785047417170330875956138182105901767368657881^10)
********** Factor found in step 1: 8349872936935826450829882263387
Found probable prime factor of 31 digits: 8349872936935826450829882263387
Composite cofactor 40866985545846521048453193355520513526503240765554925877353723400485544483604953923826252458151948382470863922759727058989786327240642768290326542226332321865881692141018216421787423442300724000665825199595659330779350921450136560086140658305570640678959955814433678115192087305648210585291332471320245185635679498732804767101607334727832647486861621247079329135407136244608771259695022713694923620212185008598968345925618935356337653 has 434 digits

sigma(1631164874282493956886307^22)
********** Factor found in step 2: 169857056796434447746180363
Found probable prime factor of 27 digits: 169857056796434447746180363
Composite cofactor 1320467393510333024063211346076966466841344987176326750859641480884859799715831190718922798242061399416850605702085108236324986714042557397410124477729323138456022508589978108810244870449688608291500588432566165553552080036035942805450939317070299207327690658843986018600930517027023290324882482769797573657266419012869498740082495472091303138026148957934947790768632964871414242387818077191548080621282553735011441988430478473037832933580692517198691579992539673491431 has 469 digits
[/code]
Chris K

[QUOTE=chris2be8;232642]The alim of 8000000 was because factMsieve.pl lowers alim to the start of the range it is sieving from.

I've restarted with alim and rlim just under 2^24 from q0: 3e6 and I'm getting a better yield even though alim gets lowered to 3e6. Hopefully the yield will rise further as alim rises.

The numbers with exponent 16 seem the hardest to handle. I'm almost wondering what an inverted octic would yield (at a guess even worse though). But I don't plan to try it, I'm more limited by human time than CPU time.

Thanks for the advice though!

Chris K[/QUOTE]

I was working on a polynomial chooser for SNFS factorizations (specifically for the odd perfect project) about 6 months ago. I'm attaching it here in case you or someone else finds it useful. The metrics are only half-baked, but it tries to estimate the (log of the) effort required for various polynomials. I ran out of time before I could finish it. I'm sure lots of folks on the forum could recommend improved estimates.

One more result:
sigma(18041^42):
r1=846126399222253639420487670576156969521047338120896029474041329110013 (pp69)
r2=135426587507029610408100819035371891457760142878407814770672813795782498399 (pp75)

No more ECM results, I've finished 1 curve at 3E6 against everything in t1200.txt. How much p-1, p+1 and ECM have been run against them, I'm wondering if p-1 or p+1 would be more cost effective than ECM?

Chris K

ECM towards p50 by yoyo@home found this p49, saving the NFS factorization
[code]sigma(3221,58) = P49 * P104

P49: 4187411465746443851965730786432472142030602773179
P104: 11578859994289585962788903706727722276478611473383633819079738873056500991287941273954277589513036337893
[/code]

Another result:
sigma(217081^30):
r1=132883127965541779603133141099647960961486176894560469 (pp54)
r2=5317613337469178892564229124327778444553412665772353373089326643138525852814621227771 (pp85)

I would have posted it earlier, but mersenneforum.org locked up on me.

Chris K

And another:
sigma(926659^28)
r1=7892247161280771044859798190887909435039422985794643101 (pp55)
r2=36096359295529807517688919847790933188120139266525047350948270612809255451089225056386069689 (pp92)

Chris K

One more:

sigma(30941^40):
r1=71241324717871904734237072306645377856814262516307521318979646514277 (pp68)
r2=446507703883500494604423145413264927598208355225624679133946196988827605251701927 (pp81)

Chris K

From Pascal's t600.txt, sigma(571^72) = P50 * P57 * P90

ECM to t50 by yoyo@home
SNFS sieving by RSALS
Post Processing by Lionel Debroux

[code]sigma(571^72) = P50 * P57 * P90

P50: 26386891018759314236196466940037349919451259404889
P57: 591872886509135249796335715865365136847433393908176875571
P90:
657774081749910492615766542057725047742640115655851832517033424113696223608856837236143399

[/code]

For more background see Pascal's web [URL="http://www.lri.fr/~ochem/opn/"]site[/URL]. Composites from [URL="http://www.lri.fr/~ochem/opn/t600.txt"]t600.txt [/URL]are "first composites" encountered in the factor chain proof that there is no odd perfect number less than 10^600. These factors are desired because they will always be used even at higher bounds - the later discovery of other factorizations will never cause these factorizations to disappear from the factor chain.