How do you get around the |a|<2^31 problem in ggnfs?

[fivemack]

I'm trying a C132 from the homogeneous Cunningham project; the SNFS difficulty is 190.8 so I think GNFS is the right way to go.

I'm using a real and algebraic factor base size of 2^24 with 28-bit large primes on both sides, and the lasieve14e siever. I get plenty of relations, but the merging process doesn't recognise about 2/3 of them.

My suspicion is that procrels is requiring |a|<2^31, which, since I am using quite a large lattice-sieve region and a rather skewed polynomial, is ruling out a large proportion of the relations I've found (which seem to go up to |a| ~ 2^33). Changing that restriction sounds as if it would require a re-write of relation handling throughout ggnfs, which is nobody's idea of fun but which I suppose someone might have done; failing that, is there a way of restricting the skew of the polynomial found by the Murphy polynomial selector so that the a/b ratio of the smooth points found isn't quite so huge?

[jasonp]

Originally Posted by fivemack

My suspicion is that procrels is requiring |a|<2^31, which, since I am using quite a large lattice-sieve region and a rather skewed polynomial, is ruling out a large proportion of the relations I've found (which seem to go up to |a| ~ 2^33).

GGNFS was modified a long time ago to allow 63-bit 'a' values throughout, including in procrels. That being said I haven't audited the code.

jasonp

[fivemack]

Ah, yes, it turns out to be just a matter of using the CVS version of the ggnfs tools.

This has landed me (on a different number) with an oversieving problem: I get a 700k x 2.2M matrix, whose starting weight is enormous and whose weight goes up badly when the pruner tries to prune it. Even with -maxrelsinff 8 the matrix had that problem; I've ended up rebuilding ignoring the last day's sieving, and hope that will work better. Am I missing some parameter for 'throw away all but the lightest million FFs'?

[Phil MjX]

Hello,

Instead of ignoring sieving work, you can try to change your params (by reducing the factor base) to force ggnfs to dump and reprocess the relations that doesn't fit in the new factor base. You can dump the rels by hand in the shell but be aware that you'll obtain many "small" files you'll have to merge for a convenient manual re-injection in ggnfs. Doing so, you eliminate the oversieved part and speed the matrix stage. I don't have experience on the -prune option.

For info, I have just finished a c131 with much lower params (a 6000000 sized factorbase and 27 bits large prime) that runs smoothly in 4 weeks on a 512 megs of ram machine (but like you I have chosen the lasieve14e siever)...

Regards.
Philippe.

[frmky]

If you're using the CVS version, try running with maxrelsinff 0. prune works well for removing up to about 10% of the relations. Beyond that it didn't seem to work well in the few cases I've run. Reducing the factor base to eliminate many of the relations is also a good idea.

Greg