Vendored ARPACK fails to converge

[szhorvat]

The igraph_arpack_rnsolve test will fail when the A matrix is filled with random integers between -10 and 10:

https://github.com/igraph/igraph/blob/master/tests/unit/igraph_arpack_rnsolve.c#L140

igraph_rng_get_integer(igraph_rng_default(), -10, 10);

Output:

LI: vector corresponding to eigenvalue (12.0475 + 6.4709*i) is not an eigenvector, coordinate 0 differs by 0.3721 + 0.1388*i

This came to light after fixing the random integer generator, #1989.

External ARPACK 3.8 does work correctly.

For now, I "fixed" the test by changing the -10..10 range to -12..12, but this is really just hiding the problem. This is likely related to #1641.

[szhorvat]

For reference, the bad matrix triggering the instability is the following:

-7 -1 10 3 8 1 -5 10 -9 -1
-7 1 0 8 -5 4 -8 1 1 6
7 -8 8 6 -5 -9 -2 -8 -4 -8
6 8 -5 -2 10 3 7 7 -4 -9
1 -8 -5 9 -1 5 5 6 -9 10
-10 10 -6 -10 5 3 -6 7 -8 10
-4 0 8 -7 -3 -8 1 -4 -9 1
2 0 9 -4 0 -10 -5 0 10 0
-10 1 -7 -2 7 10 9 9 8 -3
-8 1 9 -8 10 -2 -3 -6 7 6

[vtraag]

I've been looking at it a bit, it seems that setting

    options.ncv = DIM;

instead of

    options.ncv = 9;

also alleviates the problem (and so keeping the original "bad" matrix). I am not exactly sure why this would cause this issue, but perhaps there's some issue with non-matching eigenvectors and eigenvalues for complex conjugate pairs?

[vtraag]

I have looked into this a bit further, and I can't figure out what the problem could be. The incorrect eigenvectors only appear when using ncv = 9, not for any other valid ncv value (ncv >= nev + 2).

The resulting vectors when using ncv = 9 are not even eigenvectors themselves in any way (the first pair of columns are always correct, the second pair of columns not).

When setting ncv = 0, it is automatically selected, which happens to go OK in this case (it is then set to 2*nev + 1 = 7).

The problem is especially annoying since it of course only appears with the vendored library. It seems that all is working correctly from igraph, so the problem might be in the actual source code of the vendored library and we probably don't want to start messing with those sources.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[szhorvat]

This issue should have a minimal example attached.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[szhorvat]

It should be tested whether this problem is still present.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.