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 
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 linearalgebra 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 linearalgebra 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 linearalgebra. 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ë 
In reply to this post by Rik4
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.4093e01 1.2434e+00 4.3737e01 1.3878e17 4.0950e01 2.7068e01 5.5511e17 1.8486e17 8.0222e03 >> [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 builtin function [Builtin functions don't have tests?] Dan 
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? 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 selfconsistentcy. The function is consistent in that it produces outputs and the %!test blocks pass. But because it isn't Matlabcompatible 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 builtin function > > [Builtin functions don't have tests?] > 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 
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 builtin function > > [Builtin functions don't have tests?] Not after installing since the source with the tests is no longer available. 
In reply to this post by Rik4
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 selfconsistentcy. The function is consistent in that it > produces outputs and the %!test blocks pass. But because it isn't > Matlabcompatible 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 
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 builtin function >> >> [Builtin 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 builtin functions are installed. See '__octave_config_info__ ("octtestsdir")' for the location. But for builtin functions, they can't be found by function name. You have to run "test filethatcontainsthebuiltinfunction" 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 
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 builtin function >> >> [Builtin 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 "runoctave" doesn't find this. Dan 
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 
Free forum by Nabble  Edit this page 