Re: unsymmetric eigenvalue update

[Patrick Alken <patrick.alken@colorado.edu>]

As promised, I made a new patch with some updates. I have
posted the patch and a test program at:

http://ucsu.colorado.edu/~alken

The patch is against the latest CVS.

Changes over the CVS version include:

* updates to linalg.texi and eigen.texi
* support for computing the full Schur form T and Schur vectors Z
  (this will be needed later for computing eigenvectors) Use the
  -z option in the test program to test this

Patrick Alken

On Mon, Aug 14, 2006 at 08:59:25AM -0600, Patrick Alken wrote:
> Thanks for the update. I have a new balance and hessenberg
> routine too that I fixed up a while back. Its no longer necessary
> to do any dynamic allocation for the hessenberg function.
> I also modified the francis routine a little more to
> work better on ill-conditioned matrices and reduce more roundoff
> error. Also, I modified linalg.texi and eigen.texi to give
> complete documentation on all the functions I've added.
> I will make a new patch against the latest CVS and post it as soon as
> I can.
> 
> An update regarding the high-performance eigensolver: I've
> been working on implementing the high-performance small bulge
> aggressive early deflation method, and currently have a completely
> working code. Unfortunately, the performance is currently about
> twice as slow as the fortran version which is going to be in the
> next lapack release. I already made gsl_matrix_{get,set} macros
> and disabled range checking which resulted in about a 30% speed
> improvement. I also made optimized versions of the householder
> transform routines specifically for 3-by-1 vectors, but it still
> does not match the speed of the fortran version. I am still
> investigating why.
> 
> Another issue here is that I had to port about 4 lapack routines
> over to GSL to get the high-performance eigensolver to work.
> Plus the code for the eigensolver is heavily based on the fortran
> code which will be in lapack. I know there have been discussions
> on this list in the past regarding lapack licensing issues and
> I confess I don't fully understand whether it is acceptable/legal for
> GSL to contain lapack ported code.
> 
> Due to the sheer amount of code needed to get the high-performance
> eigensolver to work (currently about 4500 lines) mainly due to
> the large lapack routines, I'm starting to wonder if its worth it.
> Most of this code is only useful in terms of the eigenvalue problem
> and won't be useful for more general linear algebra problems. So
> all this code is there for just solving one problem and it might
> be wiser to go with the simpler francis solver whose code would
> be easier to understand/maintain. The rest of GSL seems to have
> the goal of containing small and simple to understand algorithms
> and all of this lapack code might just "uglify" the library. Any
> comments on this?
> 
> Patrick Alken
> 
> On Mon, Aug 14, 2006 at 03:24:08PM +0100, Brian Gough wrote:
> > At Tue, 13 Jun 2006 09:56:20 -0600,
> > > I propose adding the double-shift method to gsl (assuming it
> > > passes any further tests needed) which would be a perfectly
> > > fine eigenvalue solver (EISPACK used it for a number of years)
> > > until I (or someone else) can find the time to implement method 3.
> > > 
> > > Attached is the latest (final? :)) patch.
> > 
> > The latest patch is in sources.redhat.com CVS with some extra
> > cleanups.  It works well.  I modified the balance() routine to return
> > the diagonal scaling elements D (for computing the eigenvectors later)
> > and moved the memory allocation up out of hessenberg() into the
> > workspace.
> > 
> > -- 
> > Brian Gough
> > 
>