GGNFS questions and Answers

[Mystwalker]

Originally Posted by smh

Today i've done some tests with a newer version of GGNFS and all my (small) test numbers fail all 32 dependancies.

IIRC, this ggnfs problem occurs now and then - I guess you've already seen corresponding posts in the ggnfs Y!group.

I don't know the current status of that problem, though...

[smh]

Originally Posted by Mystwalker

IIRC, this ggnfs problem occurs now and then - I guess you've already seen corresponding posts in the ggnfs Y!group.

I don't know the current status of that problem, though...

Thats one of the reasons i never switched to the sourceforge version. But now i also have the problem with the original 0.77.1 version which NEVER gave me this problem before.

It doesn't even produce a trivial factorisation but gives me an error on all dependancies. I'll download a newer version of cygwin and will try again.

[VJS]

c102=prp51^2

Well maybe it wasn't that bad on an attempt or not noticing that the composite was an even number etc...

Of course I ecm'ed the number up to 30-digits and a few 40-digit curves.

I also check to see if composites are c^0.5=prp or c^1/3=prp (this would also take care of cases such as c^0.25=prp, I know it's probably silly to do so but it doesn't take much time or effort.

smh,

I'm nowhere near giving good advise yet but there is one stage of the process I believe procrels where you specify a value or 32. Using 40 or some higher number would throw out some relations, you could then do more sieving and another matrix.

Not sure about the size of the composite your working with but are you sure your problem couldn't be solved with a little ECM ? Perhaps your composite simply consists of several small numbers... Isn't it true that GGNFS doesn't work with a composite that will factor into 4 (or is it 5) smaller primes?

II would expect that such a case would be relatively difficult to solve during the sqrt step.

[smh]

Originally Posted by VJS

smh,

I'm nowhere near giving good advise yet but there is one stage of the process I believe procrels where you specify a value or 32. Using 40 or some higher number would throw out some relations, you could then do more sieving and another matrix.

Not sure about the size of the composite your working with but are you sure your problem couldn't be solved with a little ECM ? Perhaps your composite simply consists of several small numbers... Isn't it true that GGNFS doesn't work with a composite that will factor into 4 (or is it 5) smaller primes?

II would expect that such a case would be relatively difficult to solve during the sqrt step.

I tried known factorizations. The tst250 example that comes with GGNFS, a smal 75 digit SNFS number and a ~100 digit SNFS number with known 40 and 60 digit digit factors.

this pc never failed a single number out of the > 50 i've done with this version. Ranging from 95-115 digits GNFS and 140 -160 Digits SNFS.

It's not my main GGNFS pc (a notebook which needs to be brought along quite often and frequently needs more than 1Gb of RAM for other applications).

[VJS]

smh,

Did you want to post the number?

------------------------------------

I think I'm getting the hang of this the c108 tried yesterday is already done that was quick:

Number: 108
N=919062186198234152464200793844808008450484748377718640974162422865034761387771197440624749285298225234598373
( 108 digits)
Divisors found:
r1=60469313259230108568170634059938013032851923305721 (pp50)
r2=15198819643580909975786842496909146989599229476942711944013 (pp59)
Total time: 17.32 hours.
Scaled time: 10.29 units (timescale=0.594).

[trilliwig]

Originally Posted by Mystwalker

IIRC, this ggnfs problem occurs now and then - I guess you've already seen corresponding posts in the ggnfs Y!group.

I don't know the current status of that problem, though...

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.

[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.

Thats the one. I've been reading about it on the mailing list and it was the main reason i didn't upgrade since the latest version on Chris M's site (Is he still working on GGNFS?).

Strange thing is that i NEVER had this failure on 3 pc's with the original 0.77.1 (at least 150-200 factorizations in total)

Only after trying the sourceforge version i've got this problem, even in the original version. Recompiling also didn't solve it. I just tried a few small examples. Don't feel like wasting a couple of days.

I'll reinstall Cygwin this comming weekend (even better, i might just format and reinstall the OS).

I'm a little lost in all the changes on sourceforge. Are there any speedups in any of the programs or is it just bug fixes?

[frmky]

I've had that happen quite a few times. Often, rerunning procrels with -prune 0.01, then matbuild/matsolve/sqrt's again fixes the problem. If the problem persists, repeat as needed.

Greg

[trilliwig]

Originally Posted by smh

(Is he still working on GGNFS?).

Not sure what Chris Monico's up to these days. I haven't heard from him in a while. He's still teaching at TTU tho, if his course information is accurate.

Originally Posted by smh

I'll reinstall Cygwin this comming weekend (even better, i might just format and reinstall the OS).

I doubt that would help this problem, but hey, computers always like a clean reinstall. Anyway, Cygwin has its own set of problems that I've given up trying to debug. Problems like this one reported here just confound me, as the only fixes proposed are to reinstall Cygwin. If I'm running on Windows, I tend to use MinGW-compiled executables instead. Tom Cage reports a lot of his problems went away when he stopped using Cygwin.

Originally Posted by smh

I'm a little lost in all the changes on sourceforge. Are there any speedups in any of the programs or is it just bug fixes?

Mostly it's bugfixes, portability improvements, and code/compile process cleanups. There was a move to 64-bit a values in procrels/sqrt which should mean that less sieve relations are lost because of the limited range of a 32-bit signed value, but that should only help significantly in huge factorizations of numbers probably beyond GGNFS's current capability. There were also some tweaks to polynomial search parameters which should get you good polynomials faster, but you can pick those improvements up by just updating your def-nm-params.txt file.

--
Sam

[VJS]

Sam

Could you post the contents of your most updated def-nm-par.txt...

I've made quite a few mistakes and I'd like to be sure I'm using the most recent for nov '06.

I'm most interested in ggnfs for 100-115 of course.

[tcadigan]

from the ggnfs cvs.