new gsvd function incompatible w/Matlab

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

new gsvd function incompatible w/Matlab

Rik-4
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: new gsvd function incompatible w/Matlab

Carnë Draug
On 17 August 2016 at 16:28, Rik <[hidden email]> 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.
>

That is my fault.  I assumed that the function in the linear-algebra
package would behave the same because it was named the same, so I told
Barbara to just make it work with Octave and fix the code duplication
issues.

The code on the linear-algebra had tests and again I assumed the tests
would cover any Matlab compatibility issues.  The tests also got moved
into Octave.

Nir and Barbara, could you comment on this differences?  I too do not
know much about linear-algebra.  Barbara, could you come up with more
tests for this that will cover the incompatibilities?  And double check
that the existing tests really are Matlab compatible?

Carnë

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: new gsvd function incompatible w/Matlab

Daniel Sebald
In reply to this post by Rik-4
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?

What is important is that the function is consistent.  There is an
example in the documentation:

>> a = hilb (3);
>> b = [1 2 3; 3 2 1];
>> [u, v, c, s, x, r] = gsvd (a, b);
>> u' * a * x
ans =

   -1.4093e-01  -1.2434e+00   4.3737e-01
   -1.3878e-17  -4.0950e-01   2.7068e-01
    5.5511e-17  -1.8486e-17  -8.0222e-03

>> [1 0 0; [0;0] c] * [r]
ans =

   -0.14093  -1.24345   0.43737
    0.00000  -0.40950   0.27068
    0.00000   0.00000  -0.00802

The two sides of the equation seem correct.

Note, the following error messages don't seem accurately descriptive:

>> demo gsvd
warning: demo: no function gsvd found
warning: called from
     demo at line 117 column 5

[No function gsvd found?  I just called it.]

>> test gsvd
????? gsvd is a built-in function

[Built-in functions don't have tests?]

Dan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: new gsvd function incompatible w/Matlab

Rik-4
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.

>
> 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.

> Note, the following error messages don't seem accurately descriptive:
>
>>> demo gsvd
> warning: demo: no function gsvd found
> warning: called from
>     demo at line 117 column 5
>
> [No function gsvd found?  I just called it.]
>
>>> test gsvd
> ????? gsvd is a built-in function
>
> [Built-in functions don't have tests?]
>
This works for me using run-octave

octave:1> demo gsvd
warning: demo: no demo available for gsvd
warning: called from
    demo at line 120 column 5
octave:2> test gsvd
PASSES 16 out of 16 tests

--Rik

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: new gsvd function incompatible w/Matlab

Carnë Draug
In reply to this post by Daniel Sebald
On 17 August 2016 at 17:05, Daniel J Sebald <[hidden email]> wrote:
> [...]
> What is important is that the function is consistent.

No it is not.  If the function is Matlab incompatible, it will eventually
be fixed for that.  Then we will have issues of backwards incompatibility.

Even if it never gets fixed, it's just plain confusing to have a function
with the same as Matlab that is incompatible, specially when the differences
are subtle.

> [...]
>>> test gsvd
>
> ????? gsvd is a built-in function
>
> [Built-in functions don't have tests?]

Not after installing since the source with the tests is no longer available.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: new gsvd function incompatible w/Matlab

Daniel Sebald
In reply to this post by Rik-4
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: new gsvd function incompatible w/Matlab

John W. Eaton
Administrator
In reply to this post by Carnë Draug
On 08/17/2016 12:41 PM, Carnë Draug wrote:
> On 17 August 2016 at 17:05, Daniel J Sebald <[hidden email]> wrote:

>>>> test gsvd
>>
>> ????? gsvd is a built-in function
>>
>> [Built-in functions don't have tests?]
>
> Not after installing since the source with the tests is no longer available.

As far as I know, "test fcn_name" only works for .m files and .oct
files.  I don't know how it worked for Rik.

Tests for built-in functions are installed.  See '__octave_config_info__
("octtestsdir")' for the location.  But for built-in functions, they
can't be found by function name.  You have to run "test
file-that-contains-the-built-in-function" instead.  And test doesn't
search for the file or do tilde expansion.  And then you are running all
the tests in the file, not just the ones for the function you are trying
to test.  It would be nice to fix all of these things, but life is short.

jwe

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: new gsvd function incompatible w/Matlab

Daniel Sebald
In reply to this post by Carnë Draug
On 08/17/2016 11:41 AM, Carnë Draug wrote:
> On 17 August 2016 at 17:05, Daniel J Sebald <[hidden email]> wrote:

>> [...]
>>>> test gsvd
>>
>> ????? gsvd is a built-in function
>>
>> [Built-in functions don't have tests?]
>
> Not after installing since the source with the tests is no longer available.

Oh.  It must be because I built outside of the source tree that
"run-octave" doesn't find this.

Dan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: new gsvd function incompatible w/Matlab

Daniel Sebald
In reply to this post by Daniel Sebald
On 08/17/2016 12:21 PM, Daniel J Sebald wrote:

> 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.

Also, unless the documentation calls out a certain property of the
results, e.g., singular values are ordered largest to smallest, it may
be difficult to exactly match Matlab, because it might be the underlying
numerical algorithm that determines the outcome.  That is, we could make
a particular example match what Matlab does, but then there could be
some other set of matrices in the space for which the outcomes are
different just because of the internal algorithms are different.

Dan

Loading...