Re: new gsvd function incompatible w/Matlab

[Daniel J Sebald]

On 08/17/2016 11:22 AM, Rik wrote:
> On 08/17/2016 09:05 AM, Daniel J Sebald wrote:
> > On 08/17/2016 10:28 AM, Rik wrote:
> > > All,
> > >
> > > I don't want to look a gift horse in the mouth, but the new gsvd function
> > > doesn't calculate the same values as Matlab.  This is a shame, because no
> > > one with existing Matlab gsvd code will switch to Octave unless it is clear
> > > that they can get the same results.  I filed a bug report about it here
> > > (https://savannah.gnu.org/bugs/index.php?48807).
> > >
> > > If we are lucky, it is simply a matter of recombining the outputs in a
> > > different format, but I am not a linear algebra expert so I haven't tried.
> > >
> > > --Rik
> >
> > What is not the same?  (I haven't looked closely.)  Is it something like
> > the order of generalized eigenvalues/vectors?
> Order of outputs is different, which is easily fixed but still does need
> fixing.  The real issue is that the calculated results are different.  I
> suspect that we just need to combine our outputs in a certain way, maybe
> multiply two of them together or take a transpose, in order to get the same
> results as Matlab.

Generally speaking, the field of linear algebra has always disregarded 
things like singular value order, unless it is specifically called out. 
 Don't know why, maybe because there are different numerical approaches 
to solving such problems and placing them in a particular order requires 
extra computations.  Leave it up to the user I guess.


> > What is important is that the function is consistent.  There is an
> > example in the documentation:
>
> I want more than self-consistentcy.  The function is consistent in that it
> produces outputs and the %!test blocks pass.  But because it isn't
> Matlab-compatible it won't get adopted.

I think I've come across some examples elsewhere in which roots, 
eigenvalues, etc. are not the same order as a Matlab example, but I've 
always disregarded that.

Dan