error ggnfs

[jjcale]

I got the following errors when factoring
N=1881116540915762950031529944933685104293720324782004613573249083303659602952856297
:

Error: Couldn't find (919, 1) in the primes list!
=> "../../bin/sqrt" -fb rsa270.fb -deps deps -depnum 32
depNum=32 is invalid. It should be in [0,31].


I compiled ggnfs on Suse 11.3, x86_64, Athlon 3200+ .
However, since I got segmentation fault for gnfs-lasieve4I12e, I used the binarys from http://physics.fullerton.edu/gchilde...eve4_64.tar.gz.

Here the report :

Number: rsa270
N=1881116540915762950031529944933685104293720324782004613573249083303659602952856297
( 82 digits)
Divisors found:
Version: GGNFS-0.77.1-20060722-k8
Total time: 0.15 hours.
Scaled time: 0.09 units (timescale=0.588).
Factorization parameters were as follows:
name: rsa270
n: 1881116540915762950031529944933685104293720324782004613573249083303659602952856297
m: 4006612808678737740
deg: 4
c4: 7299720
c3: -3826746078
c2: -1167030186582763
c1: 11345863296076872
c0: 123728798978468277817
skew: 1379.250
type: gnfs
# adj. I(F,S) = 46.248
# E(F1,F2) = 3.491876e-03
# GGNFS version 0.77.1-20060722-k8 polyselect.
# Options were:
# lcd=1, enumLCD=24, maxS1=52.00000000, seed=1310322434.
# maxskew=1500.0
# These parameters should be manually set:
rlim: 350000
alim: 500000
lpbr: 24
lpba: 24
mfbr: 37
mfba: 37
rlambda: 1.7
alambda: 1.7
qintsize: 10000

type: gnfs
Factor base limits: 350000/500000
Large primes per side: 3
Large prime bits: 24/24
Max factor residue bits: 37/37
Sieved algebraic special-q in [250000, 420001)
Primes: RFBsize:29977, AFBsize:41386, largePrimes:747628 encountered
Relations: rels:703292, finalFF:80791
Max relations in full relation-set: 32
Initial matrix: 71441 x 80791 with sparse part having weight 2377644.
Pruned matrix : 61700 x 62121 with weight 1651104.
Polynomial selection time: 0.11 hours.
Total sieving time: 0.00 hours.
Total relation processing time: 0.02 hours.
Matrix solve time: 0.01 hours.
Time per square root: 0.00 hours.
Prototype def-par.txt line would be:
gnfs,81,4,maxs1,maxskew,goodScore,efrac,j0,j1,eStepSize,maxTime,350000,500000,24,24,37,37,1.7,1.7,10000
total time: 0.15 hours.
--------- CPU info (if available) ----------
[ 0.270586] CPU0: AMD Athlon(tm) 64 Processor 3200+ stepping 02
[ 0.000000] Memory: 1008488k/1048512k available (4775k kernel code, 452k absent, 39572k reserved, 6607k data, 896k init)
[ 13.034156] EDAC amd64: This node reports that Memory ECC is currently disabled, set F3x44[22] (0000:00:18.3).
[ 0.002005] Calibrating delay loop (skipped), value calculated using timer frequency.. 4020.50 BogoMIPS (lpj=2010250)
[ 0.273084] Total of 1 processors activated (4020.50 BogoMIPS).

[Batalov]

It appears that all of the 32 dependencies (they are numbered in the metioned range [0,31]) didn't produce a factorization.
The error "depNum=32 is invalid" is not important (and the "couldn't find..."); it is just something that the binary says when it is out of dependencies.

It seems that you don't have an installation problem (if binaries were not found by the perl script or not executable). You problem may be subtle (search the forum; there are cases where there are not enough relations to produce a solvable matrix, but the script doesn't know that) and not easily debuggable for the lack of interest (or support for that script and its binaries) - see below.

This has to do with that virtually nobody uses the factLat.pl script anymore. (Instead, use factMsieve.pl or factmsieve.py ) I have run your input number without any problems and the factorization was complete with the default use of factMsieve.pl

Additionally, the input number is practically outside of area of GNFS's normal use. It is known that QS is faster than GNFS under 85-ish digits. Instead obtain yafu or msieve binary and run this:

echo "siqs(1881116540915762950031529944933685104293720324782004613573249083303659602952856297)" | yafu
# or this
msieve 1881116540915762950031529944933685104293720324782004613573249083303659602952856297

Good luck!

[henryzz]

I seem to remember there being a bug in the programs used by factlat in the latest non-svn code. It caused all the sqrts to not work sometimes. It was fixed in svn I think.
Try compiling the svn code or even better using factmsieve.pl/py.

[jjcale]

Thanks for the tips.

When I use factMsieve.pl, it works .
However, I had to replace gnfs-lasieve4I11e by gnfs-lasieve4I12e in factMsieve.pl, since the compiled version of gnfs-lasieve4I11e gets segmentation fault, and gnfs-lasieve4I11e is not contained in physics.fullerton.edu/gchilders/gnfs-lasieve4_64.tar.gz .

It's true, that this number can be factorized by yafu via siqs much faster.

[R.D. Silverman]

Originally Posted by jjcale

<snip>

Is Greg on vacation? The NFS@Home status page is somewhat dated.

[Mathew]

From NFS@home message board

Originally Posted by Greg

It's been a crazy new year so far, so I'm somewhat behind updating the website. You may have noticed over at the Cunningham project that 10,590M is done. 2,2382M is still listed as not yet started, but really sieving is nearly done. I've done a trial filtering of M1061, and it needs a bit more sieving. Hopefully 2-3 more weeks will be sufficient.