GGNFS questions and Answers

[VJS]

OH MY GOD!!!



~63K relations required getting ~0.004rels/sec
I'm also getting alot of full relations in a short period.
You are the MAN!

This one will factor before I finish this post... well maybe not that fast.

[VJS]

A little more info...

N=9457369653229198574152180841400293605364169399903721512534521932945942523900481643194639108070247099937781485391
( 112 digits)
SNFS difficulty: 0 digits.
Divisors found:
r1=4765308303202196774211654258287707591245895974659353189 (pp55)
r2=1984629126068092087273858409023167378251747572335981133219 (pp58)
Version: GGNFS-0.77.1-20050930-athlon
Total time: 1.05 hours.
Scaled time: 0.62 units (timescale=0.590)

Initially it would only find the trivial solution, but an additional 10k of sieveing and subsequent steps produced the above factorization. I think I spent more time using ecm.

[smh]

Originally Posted by trilliwig

It's probably this bug, which is still to be fixed and affects all 0.77.1 versions. I think it's one of those bugs that require some serious data dump routines to be written to get a handle on what's going on.

I've copied all cygwin executables and the perl script from a P4 on which i have no problems to my laptop, but still all dependencies fail with this error, so i guess the problem doesn't lie in the compiler.

But then what? Cygwin, perl, bash, OS, etc...?

[ValerieVonck]

Hi group.

I have reserved a cofactor @ the "Factorizations of near-repdigit numbers" page.

It is the following number:

(34*10^155-43)/9 =
3(7)154^3 = 11 * 520702915570613 * 5555018987718121828955407 *
11873210439737767451035122054708993871651997669317256077773011377980558358143094724303201881139647072388348517121573

It is the largest number. Is it enough to do

c:\ggnfs\factlat.pl c116.n

Or does anyone else has a better suggestion?
With this I mean: should I create a poly file for (g)(s)nfs factorization?
And how should I do it?

Thx

[smh]

Originally Posted by smh

I've copied all cygwin executables and the perl script from a P4 on which i have no problems to my laptop, but still all dependencies fail with this error, so i guess the problem doesn't lie in the compiler.

But then what? Cygwin, perl, bash, OS, etc...?

Installed activeperl to run in a command box.

Had to copy cygwin1.dll and cyggmp-3.dll because my executables were compiled under cygwin.

Still the sqrt failed with the same error.

I checked the dll versions with another (working) pc. cyggmp-3.dll was the same, but cygwin1.dll was different. Replacing the dll the sqrt still failed, but after redoing the matrix the first dependency found the factors.

cygwin1.dll v1.5.17 works
cygwin1.dll v1.5.18 fails

[ValerieVonck]

Did you try the latest snapshot (compiled version) @ sourceforge?

I have only 2 issues with:

- in the middle of a sieve run I get a "too many relations found...."
- when I terminate the sieve (on windows) lasieve12 crashes & when I restart the script, the script restarts the last sieve with last qstep.

Otherwise ggnfs runs smoothly.
BTW, I am searching for a small SNFS number to factor.
If anyone is kind enough please provide with a link // poly file.

Thank you.

[VJS]

Originally Posted by CedricVonck

- in the middle of a sieve run I get a "too many relations found...."

This is b/c the step size is too large when you look at the job file, even if you continue using the script the number will still factor. I'm not sure if relations are ingored or what but this can be solved by completing one itteration via the script. Once that sieve job is finished adjust the job file...

example if this is the job...

q0: 1525001
qintsize: 74999
#q1:1600000

Change it to

q0: 1525001
qintsize: 49999
#q1:1575000

Originally Posted by CedricVonck

- when I terminate the sieve (on windows) lasieve12 crashes & when I restart the script, the script restarts the last sieve with last qstep.

It's not really crashing is it... your forcing the crash... and yes it doesn't update the q0: Again you can switch this, change q0 to the value it was at the time you ctrl-c'ed the script.

As for smaller snfs, that part of the fun... look for a program called phi in this forum. Run it on several expressions look for difficulty close to the number being factored. As above I had a c112 factor in about an hour.

[ValerieVonck]

VJS,

(and others of course) :-D

Thank you for your help!!!!
I am currently crunching factors!!! I will sure take a look @ phi...

Again thank you!!!!!

I crunched my first C99

Best regards

P.s.: Probably a st00pid question, but after a run can you leave everything the same directory & start a new run? Does the program uses the files present there ? (like the relations)?

Tx!

[VJS]

I always run each number out of a different directory nothing can be reused.

I also found a relatively easy number for you from odd perfect.

C131 143 B1=11e6
2000+ 71340621504713-1 28203019957754481116944031777820050929945196040491060153342647391345165902581480685618817581940893882839162211584379479097464035839

It looks large but I don't think it shouldn't take that long to complete phi says 0.26 Ghz days... if so that's really easy I think it should take longer???

Here would be your poly file.

n: 28203019957754481116944031777820050929945196040491060153342647391345165902581480685618817581940893882839162211584379479097464035839
c6: 1
c5: 1
c4: -5
c3: -4
c2: 6
c1: 3
c0: -1
Y1: -714060279761
Y0: 509882083132357586217122
skew: 1

It's a start let us know.

[ValerieVonck]

ok after the new C99 ... I will take this one!

[VJS]

Sorry I made a mistake in the above poly the YO and Y1 values should be different.

Y1: -713406215047
Y0: 508948427667686409212210