[QUOTE=akruppa]I've never used GGNFS yet. Which format do they use? Can you post an example?

I've made the change of x to an mpz_t, but I'll wait with the update until the GGNFS format is added, too.

Alex[/QUOTE]

This is a poly for phi(106,303) which i created with your program and changed to GGNFS format.

[CODE]n: 1080402864600262721516888437988134298194363013224363274957598124424274833407656608827361585178516639544039501769962042194612698581
# Difficulty: 136.48, skewness: 9.83, alpha: 0.00
skew: 9.83
c5: 1
c0: 91809
Y1: -1
Y0: 1976373006067208317880888847
m: 1976373006067208317880888847
type: snfs
[/CODE]

I had to make the folowing changes:

Add n: before the composite cofactor
add skew: xxxx
add type: snfs
add a colon after Y0 and Y1
Change X0-5 in c0-5:
Change capital M to m:

Thanks. I'm attaching the update with source, phi.exe and license in one zip file. Does the GGNFS format work?

The value of x can be arbitrarily large now, but autodetection only works for bases <=1000 (constant maxbase in autodet() ).

It also prints the cost of the factorisation according to the asymptotic formula for SNFS now, and an estimate how long the factorisation may take. The latter is pretty inaccurate so far as I don't have many sample points, but provides an order-of-magnitude idea of what you're getting into. I would appreciate if people could send me accurate timings of factorisations, with number, polynomial, sieving and matrix time and cpu type used.

Thanks,
Alex

Yes it produced a valid ggnfs format poly file for me.

Only the est. time (0.14 GHz days) seems a bit low to me. I'll post the time when this factorization finishes

Pascal Ochem reported an error in the program's synopsis (thanks, Pascal!). The order of n and x is reversed, the correct order is

phi [options] [n x] N

This will be fixed in the next version.

Alex

[QUOTE=trilliwig]Ah, ok, much becomes clear. So it looks like you ran polyselect standalone, using an example parameter file, which probably specified a number of iterations in the neighborhood of 1e9 or so. And by the end of it, polyselect had wrapped around some normally positive variables to negative.

So I would blame an overflow somewhere. You could call it a bug in the program, but I don't believe Chris Monico anticipated numbers this large would be entered. And I'm afraid this is also true of Kleinjung's pol51 tool, at least the version incorporated in GGNFS.

So in conclusion, I think you'll need a smaller number to do any useful self-education about NFS poly selection. :surrender[/QUOTE]

You are correct on all counts. Thank you very much for your help, it is greatly appreciated.
Joe.

[QUOTE=Joe O]You are correct on all counts. Thank you very much for your help, it is greatly appreciated.
Joe.[/QUOTE]


I am willing to advice people on polynomial selection for SNFS.

Also, anyone who sends me email at my private address can receive a
copy of my paper on optimal parameter selection for NFS.

[QUOTE=smh]Only the est. time (0.14 GHz days) seems a bit low to me. I'll post the time when this factorization finishes[/QUOTE]

That one failed to factorize :sad:
I still have the relations, but not much hope of finishing. Seems to be a bug in GGNFS.

I did anotherone: phi(53,320)
[QUOTE]n: 18584811814892129171432082860328592106857126065457043507273442950486370650673113479623824451410658307210031347962382445141065830721
# Difficulty: 137.78, skewness: 10.05, alpha: 0.00, cost: 3.3605e+014
# est. time: 0.16 GHz days (not accurate yet!)
skew: 10.048
c5: 1
c0: -102400
Y1: -1
Y0: 3602879701896396800000000000
m: 3602879701896396800000000000
type: snfs [/QUOTE]

Total sieve time was about 7 1/2 hours on a P4@2,5 GHz and a Pentium M@1,4 GHz.

The P4 is 15-20% faster, so i guess about 15-16GHz hours on the P4 and 11-12 GHz hours on the Pentium M

plus about 20 minutes relations processing, matrix and sqrt.

I did oversieve a bit, probably around 1GHz hour

I used the following (default)parameters:
[QUOTE]rlim: 1000000
alim: 800000
lpbr: 25
lpba: 25
mfbr: 43
mfba: 43
rlambda: 2.3
alambda: 2.3[/QUOTE]
If anyone has better parameters (I've got plenty RAM) i would lik to know.

Your number is a wonderful example of a few things that need to be improved in phi.c - the polynomial is horrible. For one thing, it would have been better to use -deg4 with the current phi.c. Since 53%5==3, using degree 5 (the default) causes phi.c to multiply the polynomial by x^2 which increases the difficulty by 5 and results in the large coefficient -102400 in the algebraic polynomial.

It would be even better to teach phi.c about the base splitting trick for composite bases. For example, 8*x^5-25 is a nice polynomial for your number. It may be a while before I get around to do that, though.

Alex

And I think for numbers this small it may be better to use only one large prime, say lpr = lpa = 26, mfbr = mfba = 26. If you are going to use two large primes, I'd allow the product of both to be larger than 2^43. For lp[ra]=25, try mfb[ra]=48 or 49. If your factor base limit is already 1M ~= 2^20, limiting the residual size to 2^43 (only slightly larger than fb[ra]^2) means almost all residuals >lp[ra], <mfb[ra] will in fact be prime and needlessly tested.

Alex

[QUOTE=akruppa](we need a sheep smilie!)[/QUOTE]
Hmm...

:alex:

Does that look like a sheep?

[QUOTE=Xyzzy]Hmm...

: alex:

[/QUOTE]

Hey!! Wrong tag name! :rant:

Alex

Edit: Doesn't even look like me.. grmbl...