Fri 17 Mar 2017 04:57:49 PM UTC, comment #10:
I pushed the second (eigs2.patch) to stable here (http://hg.savannah.gnu.org/hgweb/octave/rev/f093b9d4ef30).
|
Fri 17 Mar 2017 12:26:59 PM UTC, comment #9:
If it is not too late, please consider eigs2.patch instead of eigsnonsymm.patch, which also fix #39573, strongly related.
(file #40020)
|
Fri 17 Mar 2017 11:27:34 AM UTC, comment #8:
Here it is a second patch, built on top of the stable branch.
(file #40019)
|
Fri 17 Mar 2017 08:17:59 AM UTC, comment #7:
It seems I forgot to fix also the nonsymmetric generalized and the complex generalized cases. I will do.
|
Fri 17 Mar 2017 07:42:09 AM UTC, comment #6:
The first method involves B\A, which is not symmetric. It is reasonable that the problem is more difficult. The proper way to rewrite the problem is
If you try this example with 'la' instead of 'lm', eigs will tell you that the matrix is unsymmetric. Probably the test for symmetry in eigs is more stringent than my issymmetric(...,1e-14).
Now I move to #39573.
|
Fri 17 Mar 2017 07:35:27 AM UTC, comment #5:
For what it's worth, here the output of eigenvalues.m in Matlab R2016a:
So the residuals are in the same order of magnitude for the three methods in Octave and in Matlab.
|
Thu 16 Mar 2017 09:16:03 PM UTC, comment #4:
I tested the eigenvalues script all the way back to Octave-3.2.4 and it always gets an absurd result for the last method. I conclude that the generalized problem has been incorrect in Octave for years. I pushed the patch to the stable branch (http://hg.savannah.gnu.org/hgweb/octave/rev/3b2dbed26762) and it will be a part of the next bug fix release 4.2.2.
When I run the eigenvalues.m test script I find that the methods have very different accuracy.
Is this expected and acceptable, or is there something else that needs to change in Octave so the different methods are roughly equal in accuracy?
|
Thu 16 Mar 2017 08:49:47 AM UTC, comment #3:
Here it is a patch. I added three tests to eigs for the generalized problem. No test for the generalized problem with B different from the identity was present before. So, it is possible that eigs has never worked for the generalized problem.
(file #40013)
|
Wed 15 Mar 2017 05:55:47 PM UTC, comment #2:
I have not been using "chol" long enough to know if inputs have been swapped recently. I would note that eigs(B\A) produces the correct result, whereas it is the generalized problem eigs(A,B) which is incorrect. So I suspect something is being handled incorrectly for the second input matrix, B. The A matrix is handled correctly as of now.
|
Wed 15 Mar 2017 04:36:24 PM UTC, comment #1:
It seems that in EigsRealSymmetricMatrix (eigs-base.cc) the two factors of Choleski decomposition are swapped. Did chol change the output (from lower triangular to upper triangular) in the last few years? Anyway, I can produce a patch in a few days.
|
Tue 14 Mar 2017 05:29:35 PM UTC, original submission:
Have solved a generalized sparse eigenvalue problem using 3 methods: the first 2 work, the 3rd does not. Might be a bug, please see the attached script.
|