Msieve 1.51 feedback

[xilman]

linear algebra completed 3237288 of 3237790 dimensions (100.0%, ETA 0h 0m)    , ETA 11h42m)    
lanczos halted after 51197 iterations (dim = 3237288)
lanczos error: only trivial dependencies found
BLanczosTime: 54432
elapsed time 15:07:13
Some error occurred and matsolve did not record dependencies.

Oh well, I can't deal with it today. Mañana.

[xilman]

Originally Posted by xilman

linear algebra completed 3237288 of 3237790 dimensions (100.0%, ETA 0h 0m)    , ETA 11h42m)    
lanczos halted after 51197 iterations (dim = 3237288)
lanczos error: only trivial dependencies found
BLanczosTime: 54432
elapsed time 15:07:13
Some error occurred and matsolve did not record dependencies.

Oh well, I can't deal with it today. Mañana.

Sieved another 100k special-q and re-tried. This time it almost succeeded, though in a way I've never seen before. The first two dependencies yielded the same p53. The remaining 62 dependencies were all trivial. The c103 co-factor I'll finish with QS or GNFS.

...
reading relations for dependency 63
read 0 cycles
reading relations for dependency 64
read 0 cycles
sqrtTime: 1678
commencing number field sieve (103-digit input)
warning: NFS input not found in factor base file
integrator failed nan inf
R0: 0
A0: 0
skew 1.00, size 0.000e+00, alpha 0.000, combined = 0.000e+00 rroots = 0

commencing square root phase
warning: NFS input not found in factor base file
cannot handle non-linear polynomials
sqrtTime: 0
prp53 factor: 19730766037385241346601823669157368443933407293371177
c103 factor: 3317916359759806843643506842843012766667978368551852755763262052954796349074777744983847209381911066457
elapsed time 00:27:59
-> Computing time scale for this machine...
sumName = s206.000-w10_204.txt
-> Factorization summary written to s206.000-w10_204.txt.

[1]+  Done                    ../factMsieve.pl w10_204.poly

This will be the first time I've ever seen a report where SNFS didn't give the complete factorization!


Paul

[firejuggler]

square?

[Batalov]

It is not a square (or any other power).

[xilman]

Originally Posted by Batalov

It is not a square (or any other power).

Indeed. It is also well on the way to be completely factored.

[jasonp]

Did the LA report only two dependencies found?

I guess you had a very tiny nullspace, which only allowed two dependencies and hence wasn't enough to find all the factors. Doesn't explain why you only had two dependencies to work with though...

[xilman]

Originally Posted by jasonp

Did the LA report only two dependencies found?

I guess you had a very tiny nullspace, which only allowed two dependencies and hence wasn't enough to find all the factors. Doesn't explain why you only had two dependencies to work with though...

That's my guess too. It's consistent with having no dependencies in the first matrix which was build before the addition of another ~300K relations.

It's probably not related, but this number is close to the point where quintics and sextics are optimal. A quintic was used in the present case.

Still, the factorization is now complete with a p51*p52*p53 split, indicating an unfortunate ECM non-miss.

Paul

[Dubslow]

Originally Posted by jasonp

This makes me suspicious that there's a problem with the last phase of the filtering. If you still have this C97 dataset, could you comment out the call to filter_postproc_relsets at the bottom of common/filter/filter.c and rerun the filtering and LA?

Hmm... I've run across this problem again (different dataset) and attempted to follow these directions. Unfortunately, I didn't find a "filter_postproc_relsets" in filter.c. I looked in SVN to try and locate the change based on your description; filter.c hasn't changed since r23; the only recent change (at 6 weeks by now) was this, which AFAICT does not match anything like "filter_postproc_relsets".

Edit: I found a call to that function in gnfs/filter/filter.c, but that doesn't appear to have changed in quite a while either.

[jasonp]

It hasn't changed in a long while; try commenting it out and rerunning anyway. It's the first place where I see a difference in filtering output between your runs and mine.

(Maybe we have another gcc anomaly? It wouldn't be the first time...)

[Dubslow]

Originally Posted by jasonp

It hasn't changed in a long while; try commenting it out and rerunning anyway. It's the first place where I see a difference in filtering output between your runs and mine.

(Maybe we have another gcc anomaly? It wouldn't be the first time...)

You mean the call to filter_postproc_rels() in gnfs/filter/filter.c that's been there since r23? (That is to say, I see in SVN that you made some changes 6 weeks ago, but those changes don't appear to have any relationship with what, AFAICT, you want me to comment out.)

[jasonp]

I've had sharper mornings than this one. Yes, please comment out the call to filter_postproc_rels and re-run the filtering and then the LA. If the LA does not have problems then whatever weirdness is occurring is because of filter_postproc_rels.

(At this point I'm proceeding as if whatever is going on is either a hitherto-unknown problem in the algorithm that only manifests itself sporadically or with low amounts of oversieving, or a compiler issue)