GGNFS questions and Answers

[smh]

Originally Posted by trilliwig

I doubt that would help this problem, but hey, computers always like a clean reinstall.

It didn't help this time.

Completely removed cygwin and downloaded it again. Tried both the original 0.77.1 and the latest sourceforge snapshot but both fail the tsts1 test that comes with it

I tried -prune 0.01, even -prune 0.1 and some extra sieving but no luck.

Getting a little desperate now

[trilliwig]

At this point all I can offer is voodoo. Try raising your alim by 100 in your .poly file and rerun factLat.pl to force a relation dump and reprocessing. Maybe matbuild/matsolve will do something different this time.

--
Sam

[VJS]

SMH,

Would you seriously post the number? Is this a personal goal etc.
Not sure if this posting is in bad taste just trying to help.

[smh]

Originally Posted by VJS

SMH,

Would you seriously post the number? Is this a personal goal etc.
Not sure if this posting is in bad taste just trying to help.

It's the tsts1 number that comes with ggnfs in the test directory. The poly is:

n: 48112675629372767804524219707530062462251150382843481915847109420993527839223554575368891438718253
type: snfs
m:  157775382034845806615042743
c4: 1
c3: 0
c2: 0
c1: 0
c0: -539
skew: 5

[VJS]

If your running the perlscript are there any instances where a file cannot be found? I was initially having problems b/c it couldn't find cat.exe, I realise the issues are probably later in the process.

[Zeta-Flux]

I had the same problem when I downloaded ggnfs that VJS mentioned. It was missing a few files, which I had to get from another source.

[VJS]

smh,

Your other option of course would be to simply create an n: file and try using the script from scratch no snfs or anything. It really shouldn't take long for that number using ggnfs, you could also note the steps and which programs are being call see if there are any errors.

Or you could also try a different number with ggnfs, here is the c102 which factored recently...

(615751018555603968114438333611^5-1)/615751018555603968114438333610 C102

n: 766786943144303497987286814035254653570980408871310792191543539940228899146147493082215007848171327731

r1=6591339308401695643805746077211317047876598194962721 (pp52)
r2=116332494394107929871438092066112222385351385041811 (pp51)

Depending on your machine it shouldn't take more than a day, and it might give you some insight into the problem.

[smh]

Originally Posted by VJS

smh,

Your other option of course would be to simply create an n: file and try using the script from scratch no snfs or anything. It really shouldn't take long for that number using ggnfs, you could also note the steps and which programs are being call see if there are any errors.

Or you could also try a different number with ggnfs, here is the c102 which factored recently...

(615751018555603968114438333611^5-1)/615751018555603968114438333610 C102

n: 766786943144303497987286814035254653570980408871310792191543539940228899146147493082215007848171327731

r1=6591339308401695643805746077211317047876598194962721 (pp52)
r2=116332494394107929871438092066112222385351385041811 (pp51)

Depending on your machine it shouldn't take more than a day, and it might give you some insight into the problem.

I still have two other pc's which run fine. Both are doing the matrix step right now an should be finished by tomorrow morning. I'll run the same number on these pc's and see what happens.

I did try two or three other numbers on thi pc with both the original 0.77.1 and the sourceforge version and all failed with the same error.

I have literally factored hundreds of numbers with this version and haven't had a single factorization that failed (with this or any other error).

I might try the provided binaries on sourceforge but need to figure out how to run all programs manually. I'ts been a long time since i did it manually. The script makes life so much easier.

I might try a c100 with GNFS, problem is that it's hard to let this laptop run for more then a couple of hours a day without really using it. (I run a lot of virtual machines pc which are quite cpu and memory intensive)

[rogue]

I had problems with ggnfs because of the GGNFS_BIGENDIAN define. On PowerPC with gcc 4 it was not defined, but with gcc 3 it was. Since PowerPC is a big endian architecture, it should be defined. If it is not defined, the sieving step does not produce the correct output. x86 is little endian. I wonder if it is defined on x86 using Cygwin when it shouldn't be. In any case I suspect it is either a problem due to an incorrect define or it is a bug with gcc.

BTW, this versioning is rather confusing. I don't know which versions of 0.77.1 you have tested. I use the September 30th version (with a few mods) and it works fine on PowerPC. I haven't tried the current source. When a new snapshot is ready, I'll d/l it and try it out.

[ewmayer]

Originally Posted by rogue

I had problems with ggnfs because of the GGNFS_BIGENDIAN define.

Just out of curiosity, does anyone know why GGNFS cares about the hardware's endian-ness?

[jasonp]

Originally Posted by ewmayer

Just out of curiosity, does anyone know why GGNFS cares about the hardware's endian-ness?

Several of the savefile formats are binary, with little-endian assumed.

Endianness also matters in the lattice siever; it looks like it has something to do with locating sieve offsets, though I haven't examined the source enough to say more.

jasonp