-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorporate GSoC 2015 Eigensolver into Develop branch #68
base: develop
Are you sure you want to change the base?
Conversation
The Hessenberg decomposition module for square matrix is completed...
This finished the recovery of eigen values
This is needed for the computation of Eigen Vectors
eigen_solver.hpp which can compute real eigenvalyes of real matrices..
Implemented Givens rotation and modified schur decomposition for better convergence in complex case
Complex Eigen Values are supported
Documentations
Hi Thomas,
thanks for your support. It will be good to merge previous GSOC projects
and code to uBLAS. I would like to see more than four test cases. Can you
add more tests with different element types and matrix dimensions? Could
you also reference the algorithms the gsoc student has used? It will be
also good to measure the runtime and compare it with the runtime in octave
for instance before we merge the code.
Best
Cem
Am So., 21. Apr. 2019 um 05:24 Uhr schrieb Thomas <[email protected]
…:
After reviewing the code and tests produced from Rajaditya Mukherjee's
GSoC 2015 project, I wish to work towards merging this with the main
development branch.
The current develop branch does not contain methods for producing matrix
inverses. In other words, there is no solver without external dependencies
on existing routines like LAPACK, etc. Having one will allow many advanced
algorithms involving matrices and tensors to be implemented.
I'm sure there is a reason why it wasn't merged, but at the moment,
including it in the development branch would make it much more accessible
to other developers
------------------------------
You can view, comment on, or merge this pull request online at:
#68
Commit Summary
- Hessenberg
- Francis QR Step
- FRancis Double Step QR
- Transform Accumulations
- Eigen Solver Wrapper
- Givens Rotation and Modified Schur Decomposition
- Complex Eigen Values
- eigenvalue new routine
- Complex Eigenvector
- Small Numerical Fix
- Matrix Balancing
- Doxygen Comments
- SingleTest and sample
- Test Cases
- HTML Docs
- Matlab's Magic Shift Function
- Merge GSOC 2015 eigensolver into Develop branch
File Changes
- *A* doc/eigensolver.html
<https://github.com/boostorg/ublas/pull/68/files#diff-0> (146)
- *M* doc/index.html
<https://github.com/boostorg/ublas/pull/68/files#diff-1> (6)
- *A* doc/samples/eigen_solver.cpp
<https://github.com/boostorg/ublas/pull/68/files#diff-2> (54)
- *A* include/boost/numeric/ublas/eigen_solver.hpp
<https://github.com/boostorg/ublas/pull/68/files#diff-3> (395)
- *A* include/boost/numeric/ublas/hessenberg.hpp
<https://github.com/boostorg/ublas/pull/68/files#diff-4> (111)
- *A* include/boost/numeric/ublas/householder.hpp
<https://github.com/boostorg/ublas/pull/68/files#diff-5> (107)
- *A* include/boost/numeric/ublas/matrix_balancing.hpp
<https://github.com/boostorg/ublas/pull/68/files#diff-6> (115)
- *A* include/boost/numeric/ublas/schur_decomposition.hpp
<https://github.com/boostorg/ublas/pull/68/files#diff-7> (533)
- *M* test/common/testhelper.hpp
<https://github.com/boostorg/ublas/pull/68/files#diff-8> (25)
- *A* test/test_eigensolver.cpp
<https://github.com/boostorg/ublas/pull/68/files#diff-9> (117)
Patch Links:
- https://github.com/boostorg/ublas/pull/68.patch
- https://github.com/boostorg/ublas/pull/68.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#68>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA6PDJJHI57DTS3ZXKVVJPDPRPM5RANCNFSM4HHK3L5Q>
.
|
Really, the only reason was lack of time. I've kind of lost contact with the student too. I think he finished his PhD and was busy with his new work life, which I understand (every morning :-D ). Should I merge the branch now or we wait until you've got more benchmarks? |
I would recommend performance comparison with Eigen. I used Eigen in this PR: But of course I would've liked to remove the external dependency. |
At the very least, should we include a reference (let's say to a paper in arxiv) for each of the algorithms? I also think more benchmarks are important since the code is almost 4 years old |
@david: I would like to "wait" until we have a stable version. And we have
to review the code before any kind of merging I think. Nick if you want to
participate on the review you are more than welcome.
@nick: I fully agree. Stefan already started to write a performance
measurement library for ublas. Maybe we could do something more generic?
@thomas: Could you please include more unit tests with a higher degree of
test coverage? Also we need to compare the results with the ones from
octave. I will try to help.
@me: I will try to prepare unit-tests with which we can octave from my
previous work. I have also my own tensor performance measurement tool.
Maybe we could use that?
Am Di., 23. Apr. 2019 um 18:53 Uhr schrieb Thomas <[email protected]
…:
At the very least, should we include a reference (let's say to a paper in
arxiv) for each of the algorithms?
I also think more benchmarks are important since the code is almost 4
years old
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#68 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA6PDJJR3OY4WI65TBD5EO3PR45JPANCNFSM4HHK3L5Q>
.
|
agree, agree, agree and agree... :-D
…On Wed, Apr 24, 2019 at 5:50 AM Cem Bassoy ***@***.***> wrote:
@david: I would like to "wait" until we have a stable version. And we have
to review the code before any kind of merging I think. Nick if you want to
participate on the review you are more than welcome.
@nick: I fully agree. Stefan already started to write a performance
measurement library for ublas. Maybe we could do something more generic?
@thomas: Could you please include more unit tests with a higher degree of
test coverage? Also we need to compare the results with the ones from
octave. I will try to help.
@me: I will try to prepare unit-tests with which we can octave from my
previous work. I have also my own tensor performance measurement tool.
Maybe we could use that?
Am Di., 23. Apr. 2019 um 18:53 Uhr schrieb Thomas <
***@***.***
>:
> At the very least, should we include a reference (let's say to a paper in
> arxiv) for each of the algorithms?
>
> I also think more benchmarks are important since the code is almost 4
> years old
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#68 (comment)>, or
mute
> the thread
> <
https://github.com/notifications/unsubscribe-auth/AA6PDJJR3OY4WI65TBD5EO3PR45JPANCNFSM4HHK3L5Q
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#68 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAQOK4GT7EUF3ROBVOVHJRLPR5VQRANCNFSM4HHK3L5Q>
.
|
I added 5 more 10x10 test matrices with numbers at different orders of magnitude. I also changed the test suite so that it now covers the double and float data types. For some reason, my changes aren't showing up when I click on my new commit - any reason why this is? Right now, I'm still a bit uncertain whether the eigensolver can handle complex matrices... AFAIK Eigen has a separate eigensolver specifically for complex and hermitian matrices. I just realized that the eigensolver test suite was never added to the jamfile, so it was never run during build. For the eigensolver test suite and future test suites, do we add it manually to the Jamfile? Until then, we cannot merge anything For the new test cases I added, I also computed the same result in Eigen. Inside benchmarks I could potentially just copy the "Eigen" directory found inside the Eigen package, and then make the comparison there with the ublas eigensolver. There are also some other minor formatting changes I could do regarding some of the function signatures - adding const specifiers, etc. Some of the comments that rajaditya left also give us some unfinished tasks |
Am Sa., 27. Apr. 2019 um 23:03 Uhr schrieb Thomas <[email protected]
:
I added 5 more 10x10 test matrices with numbers at different orders of
magnitude. I also changed the test suite so that it now covers the double
and float data types. For some reason, my changes aren't showing up when I
click on my new commit - any reason why this is?
Right now, I'm still a bit uncertain whether the eigensolver can handle
complex matrices... AFAIK Eigen has a separate eigensolver specifically for
complex and hermitian matrices.
Maybe we should first compare their (Eigen/Octave) interfaces with the one
you are proposing. Could you send an email with such a comparison?
I just realized that the eigensolver test suite was never added to the
jamfile, so it was never run during build. For the eigensolver test suite
and future test suites, do we add it manually to the Jamfile? Until then,
we cannot merge anything
Yes. You need to modify the jam files so that it is build and tested as
well. Also Eigen or Octave needs to be installed for CI.
For the new test cases I added, I also computed the same result in Eigen.
Inside benchmarks I could potentially just copy the "Eigen" directory found
inside the Eigen package, and then make the comparison there with the ublas
eigensolver.
A copy of eigen solvers within the boost/ublas repo is not a good idea. It
is okay to install it for testing.
There are also some other minor formatting changes I could do regarding
some of the function signatures - adding const specifiers, etc. Some of the
comments that rajaditya left also give us some unfinished tasks
Yes. very good.
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#68 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA6PDJINFF32N6DPNOKHKFTPSS5S3ANCNFSM4HHK3L5Q>
.
|
Currently, all the tests for the eigensolver (both old ones and new ones) pass. I fixed some minor bugs in the test code and the code for the eigensolver as well. Right now the test cases are not written using the full extent of the Boost Test Suite. Could I get some guidance on that? The next step for me is adding benchmarks |
Great job !
…On Mon, May 6, 2019 at 9:49 AM Thomas ***@***.***> wrote:
Currently, all the tests for the eigensolver (both old ones and new ones)
pass. I fixed some minor bugs in the test code and the code for the
eigensolver as well.
Right now the test cases are not written using the full extent of the
Boost Test Suite. Could I get some guidance on that?
The next step for me is adding benchmarks
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#68 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAQOK4A6D7NKCPQQ6UFZXK3PT5XB5ANCNFSM4HHK3L5Q>
.
|
Hello all,
I have been following this discussion on the mailing list, and have commented
via Stackoverflow. Please see below.
All the best, Paul
On Sunday, 12 May 2019 9:45:42 PM AEST David Bellot wrote:
Great job !
On Mon, May 6, 2019 at 9:49 AM Thomas ***@***.***> wrote:
Currently, all the tests for the eigensolver (both old ones and new ones)
pass. I fixed some minor bugs in the test code and the code for the
eigensolver as well.
Right now the test cases are not written using the full extent of the
Boost Test Suite. Could I get some guidance on that?
The next step for me is adding benchmarks
Testing pull request #68 using Glucat
I have just begun testing uBLAS pr #68, that requests to merge
thomasyang1207:develop from GSOC 2015 into uBLAS. To do this, I am using a new
branch of GluCat.
I am testing using GluCat's test11, which extensively uses transcendental
functions, some of which involve matrix logarithms and square roots, which in
turn call the eigensolver to determine the (complex) eigenvalues of the
matrix. In my experience, the test becomes unacceptably slow the very first
time that the eigensolver is given a 4 x 4 matrix. I haven't yet diagnosed the
problem, but possibly the code is copying matrices more than it really needs
to?
Also. I have looked at the code itself and have quite a few comments. In this
question, I will state just one: the code reads as if it uses the word
"complex" to mean "imaginary", as in splitting a complex number into its real
and "complex" parts. This will be an unneeded cause of confusion if it is to
remain in the public interface of the code, and in fact "complex" should be
changed to "imag" or "imaginary" throughout the code, whenever it is correct
and appropriate to do so.
I have more comments, but how can I make them by performing a code review of
uBLAS pr #68 within the uBLAS repository? Who would have to grant me access? I
have a background in C++ as well as linear and multilinear algebra, and taught
numerical linear algebra at ANU 2009-2011,so I am reasonably up to the task,
if I can find the time.
Paul Leopardi
I have tested using the matrix [0 -1 0 0; 1 0 0 0;0 0 0 -1;0 0 1 0] (Matlab
notation). This produces an infinite loop in schur_decomposition, because the
matrix argument h to that function has diagonal entries that are 0, and the
function cannot cope with diagonal entries that are 0 or close to 0. Also, the
Francis algorithm assumes that the matrix is strictly upper Hessenberg, so in
this case the matrix should have been split into two 2x2 blocks before being
sent to schur_decomposition. – Paul Leopardi
PS: In fact the Francis algorithm is known to be prone to failure.
See LAWN187: Lapack 3.1 xHSEQR: Tuning and Implementation Notes
--
Paul Leopardi - https://sites.google.com/site/paulleopardi/
|
Hello all,
I have been following this discussion on the mailing list, and have
commented
via Stackoverflow. Please see below.
All the best, Paul
On Sunday, 12 May 2019 9:45:42 PM AEST David Bellot wrote:
Great job !
On Mon, May 6, 2019 at 9:49 AM Thomas ***@***.***> wrote:
> Currently, all the tests for the eigensolver (both old ones and new ones)
> pass. I fixed some minor bugs in the test code and the code for the
> eigensolver as well.
> Right now the test cases are not written using the full extent of the
> Boost Test Suite. Could I get some guidance on that?
> The next step for me is adding benchmarks
Testing pull request #68 using Glucat
I have just begun testing uBLAS pr #68, that requests to merge
thomasyang1207:develop from GSOC 2015 into uBLAS. To do this, I am using a
new
branch of GluCat.
I am testing using GluCat's test11, which extensively uses transcendental
functions, some of which involve matrix logarithms and square roots, which
in
turn call the eigensolver to determine the (complex) eigenvalues of the
matrix. In my experience, the test becomes unacceptably slow the very
first
time that the eigensolver is given a 4 x 4 matrix. I haven't yet diagnosed
the
problem, but possibly the code is copying matrices more than it really
needs
to?
Thanks for pointing this out. Maybe you could be more specific on this by
referencing a line within the code. It would be easier for Thomas
to analyze and validate.
Also. I have looked at the code itself and have quite a few comments. In
this
question, I will state just one: the code reads as if it uses the word
"complex" to mean "imaginary", as in splitting a complex number into its
real
and "complex" parts. This will be an unneeded cause of confusion if it is
to
remain in the public interface of the code, and in fact "complex" should
be
changed to "imag" or "imaginary" throughout the code, whenever it is
correct
and appropriate to do so.
Yes, you are right. Could you again reference the code lines so we that we
are able to find the culprit lines faster?
I have more comments, but how can I make them by performing a code review
of
uBLAS pr #68 within the uBLAS repository? Who would have to grant me
access? I
have a background in C++ as well as linear and multilinear algebra, and
taught
numerical linear algebra at ANU 2009-2011,so I am reasonably up to the
task,
if I can find the time.
Please feel free to also work on the pull request (maybe together with
Thomas if you and Thomas wish).
I have tested using the matrix [0 -1 0 0; 1 0 0 0;0 0 0 -1;0 0 1 0]
(Matlab
notation). This produces an infinite loop in schur_decomposition, because
the
matrix argument h to that function has diagonal entries that are 0, and
the
function cannot cope with diagonal entries that are 0 or close to 0. Also,
the
Francis algorithm assumes that the matrix is strictly upper Hessenberg, so
in
this case the matrix should have been split into two 2x2 blocks before
being
sent to schur_decomposition.
Thanks. This is why we need better test coverage. Thomas could you
reproduce those problems?
…
PS: In fact the Francis algorithm is known to be prone to failure.
See LAWN187: Lapack 3.1 xHSEQR: Tuning and Implementation Notes
|
I'll get going on reproducing this issue with ublas's test suite. The line about the complex eigenvalues is in the file eigen_solver.hpp, throughout the eigen_solver class definition. I can fix that as well @penguian I'd love to learn more about the specifics of implementing an eigensolver, since I'm actually quite new to all this. I have added you as a collaborator to my branch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The proposed code is unfinished and contains unused functions which need to be incorporated and tested. See also these pull requests and branches of which two are in progress.
For a description of the LAPACK implementation of the multi-shift QR algorithm, as used in (e.g.) DGEES
, see Lapack 3.1 xHSEQR: Tuning and Implementation Notes. This uses the double shift algorithm for small matrices.
See also the equivalent Eigen code.
* @tparam[in] m matrix type (like matrix<double>) - input hessenberg form output - schur form | ||
*/ | ||
template<class M> | ||
void schur_decomposition(M &h) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is incomplete as a practical implementation of the Francis Double Shift QR Algorithm. [1, p. 173]: "In practice, the QR iteration with the Francis shift can fail to converge ... So the practical algorithm in use for decades had an "exceptional shift" every 10 shifts if convergence had not occurred. ... another exceptional shift was recently added to the algorithm."
[1] James Demmel, Applied Numerical Linear Algebra, SIAM, 1997.
} | ||
|
||
template<class M> | ||
void find_small_diag_entry(M &h, typename M::size_type end, typename M::value_type l1_norm, typename M::size_type &small_index) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused function. See the equivalent Eigen method RealSchur<MatrixType>::findSmallSubdiagEntry
which is used in RealSchur<MatrixType>::computeFromHessenberg
. This function should be used in schur_decomposition
above, but is not.
} | ||
|
||
template<class M> | ||
void row_split(M &h, M &qv, typename M::size_type end, typename M::value_type exceptional_shift_sum) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused function. See the equivalent Eigen method RealSchur<MatrixType>::splitOffTwoRows
which is used in RealSchur<MatrixType>::computeFromHessenberg
. This function should be used in schur_decomposition
above, but is not.
} | ||
|
||
template<class M> | ||
void infer_shifts(M &h, typename M::size_type end, typename M::size_type iter_nos, typename M::value_type exceptional_shift_sum, vector<typename M::value_type> &shift_vector) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused function. See the equivalent Eigen method RealSchur<MatrixType>::computeShift
which is used in RealSchur<MatrixType>::computeFromHessenberg
. This function should be used in schur_decomposition
above, but is not.
This is the function that contains the exceptional shifts that I mentioned above at line 36. See below.
|
||
//Original Shift | ||
if (iter_nos == size_type(10)) | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is "Wilkinson's original ad hoc shift", as per the equivalent Eigen method RealSchur::computeShift.
template <class M> | ||
class eigen_solver { | ||
private: | ||
M matrix; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the source files retain tab characters, which automatically translate to 8 spaces when displayed here. These tabs should be replaced by 4 spaces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See branch clean-indentation (in progress).
MATRIX Lambda_Real(3, 3); | ||
MATRIX Lambda_Complex(3, 3); | ||
|
||
for (int i = 0; i < 3; i++){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This tests only the first 3 eigenvalues, instead of all eigenvalues. See pull request Test all eigs.
bool has_eigenvalues; | ||
bool has_eigenvectors; | ||
M eigenvalues_real; | ||
M eigenvalues_complex; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The term complex
as used here and elsewhere is misleading and should be replaced by imag
or `imaginary. See pull request API: Change misleading instances of complex to imag or imaginary.
} | ||
} | ||
|
||
for (size_type j = n; j--!=size_type(0);) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be better to have
for (size_type j = n - 1; j != 0; j--)
if that is what is meant.
"[10,10]((4, 2, 3, 4, 3, 6, 7, 8, 9, 10),(0, 2, 3, 3, 5, 0, 7, 8, 9, 10),(3, 2, 0, 4.2, 5, 6.1, 0, 8, 9, 0),(1, 2, 3, 4, 5, 6, 0, 8, 9, 1),(3, 2, 3, 4.5, 5, 6, 0, 8, 9, 0),(5, 2, 0, 4, 5, 6, 1, 8, 9, 1),(0, 2, 3, 0, 5, 6, 7, 0, 9, 4),(1, 13, 0, 4, 5, 6, 2, 8, 9.3, 0),(100, 2, 3, 0, 0, 6, 7, 8, 9, 10),(0, 2, 3, 4, 5, 6, 0, 8, 9, 0),)\0", | ||
"[10,10]((0, 2e+10, 3e+10, 4e+10, 3e+10, 6e+10, 7e+10, 8e+10, 9e+10, 1e+11),(1e+10, 2e+10, 3e+10, 3e+10, 5e+10, 0, 7e+10, 8e+10, 9e+10, 1e+11),(3e+10, 2e+10, 0, 4.2e+10, 5e+10, 6.1e+10, 0, 8e+10, 9e+10, 0),(1e+10, 2e+10, 3e+10, 4e+10, 5e+10, 6e+10, 0, 8e+10, 9e+10, 1e+10),(1e+10, 2e+10, 3e+10, 4.5e+10, 5e+10, 6e+10, 7e+10, 8e+10, 9e+10, 0),(5e+10, 6e+10, 0, 4e+10, 5e+10, 6e+10, 7e+10, 8e+10, 9e+10, 1e+10),(0, 2e+10, 3e+10, 0, 5e+10, 6e+10, 7e+10, 1e+10, 9e+10, 4e+10),(1e+10, 2e+10, 0, 4e+10, 5e+10, 6e+10, 7e+10, 8e+10, 9.3e+10, 0),(0, 2e+10, 3e+10, 4e+10, 0, 6e+10, 7e+10, 8e+10, 9e+10, 1e+11),(0, 2e+10, 3e+10, 4e+10, 5e+10, 6e+10, 7e+10, 8e+10, 9e+10, 0))\0" | ||
}; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More tests are needed, including tests which cause the current implementation to fail to converge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See branch more-eigensolver-tests (in progess).
size_type n = real_schur_form.size1(); | ||
size_type i = size_type(0); | ||
|
||
eigenvalues_real = zero_matrix<value_type>(n,n); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The real and imaginary components of the eigenvalues should be returned as vectors, especially when eigenvectors are not required. Compare with Eigen.
} | ||
|
||
if (!_fail_counter) { | ||
std::cout << "\nEigen Solver regression suite passed.\n"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Usually in C++, end of line is indicated by std::endl
. The use of "\n"
here is C usage.
} | ||
} | ||
|
||
assertTrue("Real portion of verifier is zero:", compare_on_tolerance(Lambda_Real, Zero_Matrix)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From line 121 to here: why not just compare (e.g.) norm _2(Lambda)/norm_2(prod(V,D))
with a small tolerance?
M(i, j) = std::complex<TYPE>(A(i, j), 0.0); | ||
} | ||
} | ||
Lambda = prod(M, V) - prod(V, D); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name Lambda
here is misleading, because in this context, the letter lambda
is used to denote a generic eigenvalue of a matrix. Maybe use Verifier
, since that is what the message below calls it.
|
||
value_type t = (std::max)((std::abs)(T(i, k - size_type(1))), (std::abs)(T(i, k))); | ||
if ((std::numeric_limits<value_type>::epsilon() * t)*t > value_type(1)) { | ||
for (size_type j = i; j < k + i - size_type(1); j++){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The bound of k + i - size_type(1)
here is incorrect and will cause j
to index past the end of the matrix. Compare with EigenSolver.h lines 596-598.
See thomasyang1207 pull request #5 for the fix.
Hi @thomasyang1207 . I have commented on this merge request and have made suggested changes of my own. See the branches and merge requests at https://github.com/thomasyang1207/ublas In the meantime, you can study the Eigenvalues module of Eigen and read [1] Demmel, Applied Numerical Linear Algebra, SIAM, 1997. Chapter 4 Nonsymmetric Eigenvalue Problems. (Section 4.4.8 covers QR iteration with implicit shifts, but it would be best to read from the start of the chapter.) [2] Trefethen and Bau. Numerical Linear Algebra, SIAM 1997, Part V Eigenvalues. (Lecture 29 covers the QR algorithm with shifts, but it would be best to read from Lecture 24.) |
After reviewing the code and tests produced from Rajaditya Mukherjee's GSoC 2015 project, I wish to work towards merging this with the main development branch.
The current develop branch does not contain methods for producing matrix inverses. In other words, there is no solver without external dependencies on existing routines like LAPACK, etc. Having one will allow many advanced algorithms involving matrices and tensors to be implemented.
I'm sure there is a reason why it wasn't merged, but at the moment, including it in the development branch would make it much more accessible to other developers