20110717, 10:25  #1 
Jul 2011
2^{2} Posts 
error ggnfs
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 gnfslasieve4I12e, 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: GGNFS0.77.120060722k8 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.491876e03 # GGNFS version 0.77.120060722k8 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 specialq in [250000, 420001) Primes: RFBsize:29977, AFBsize:41386, largePrimes:747628 encountered Relations: rels:703292, finalFF:80791 Max relations in full relationset: 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 defpar.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). 
20110717, 21:18  #2 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
9390_{10} Posts 
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 85ish digits. Instead obtain yafu or msieve binary and run this: Code:
echo "siqs(1881116540915762950031529944933685104293720324782004613573249083303659602952856297)"  yafu # or this msieve 1881116540915762950031529944933685104293720324782004613573249083303659602952856297 
20110718, 13:02  #3 
Just call me Henry
"David"
Sep 2007
Cambridge (GMT/BST)
2·29·101 Posts 
I seem to remember there being a bug in the programs used by factlat in the latest nonsvn 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. 
20110718, 22:47  #4 
Jul 2011
2^{2} Posts 
Thanks for the tips.
When I use factMsieve.pl, it works . However, I had to replace gnfslasieve4I11e by gnfslasieve4I12e in factMsieve.pl, since the compiled version of gnfslasieve4I11e gets segmentation fault, and gnfslasieve4I11e is not contained in physics.fullerton.edu/gchilders/gnfslasieve4_64.tar.gz . It's true, that this number can be factorized by yafu via siqs much faster. 
20120116, 19:50  #5 
Nov 2003
7460_{10} Posts 
NFS@Home Status
Is Greg on vacation? The NFS@Home status page is somewhat dated.
Last fiddled with by R.D. Silverman on 20120116 at 19:50 Reason: typo 
20120116, 21:27  #6  
Nov 2009
2×5^{2}×7 Posts 
From NFS@home message board
Quote:


Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Error running GGNFS+msieve+factmsieve.py  D. B. Staple  Factoring  6  20110612 22:23 
Error Messages from GGNFS  EdH  Factoring  4  20100101 19:52 
GGNFS or something better?  ZetaFlux  Factoring  1  20070807 22:40 
Unpacking and installing GGNFS? (error and n00bquestions)  Andi47  Factoring  1  20070322 20:58 
ggnfs  ATH  Factoring  3  20060812 22:50 