Re: eig function project

[Rafael Gonzalez]

> This way if the lapack folks
> don't fix *geev at least octave could pass the balancing counterexample given in
> the ML doc

A comment I forgot to include in the last mail, I'd say that the 'nobalance' option is in fact the workaround that Matlab came up with to avoid that feature from dgeev but it is still left to the user criteria. So, a Matlab like functionality is a must, but I was thinking that maybe including an 'auto' option that determines if balancing is required or not, could be a nice feature and a good GSoC project that would require a lot of understanding on when balancing is required.

2013/4/22 Ed Meyer <address@hidden>

On Fri, Apr 19, 2013 at 1:06 PM, Rafael Gonzalez <address@hidden> wrote:

Ok, but putting the GSoC project thing aside, I think giving the same options from Matlab is something I can begin to work on and getting involved with Octave. If it isn't good enough for a project, I'm also interested in the 1D PDEs project.

I think that changing the calls to *geev to *geevx and calls to *ggev to *ggevx
would be an easy and useful thing to do and would get us closer to ML compatibility.
Adding the 'nobalance' shouldn't be too difficult either. This way if the lapack folks
don't fix *geev at least octave could pass the balancing counterexample given in
the ML doc:

a = [ 3        -2           -.9            2*eps
        -2        4              1            -eps
      -eps/4  eps/2     -1              0
      -0.5       -0.5        0.1            1 ]

which it does not now because of the bug in dgeev.

--
Ed Meyer

--

Rafael González