I connected the templated code for gsvd in liboctave to the gsvd function in libinterp/corefcn so that inputs of single type will now call the appropriate code in liboctave and return a FloatMatrix or FloatComplexMatrix (http://hg.savannah.gnu.org/hgweb/octave/rev/f1bb2f0bcfec).
I removed the warning about using matrices of single type since it is okay now, and also added BIST tests to check this.
There is still the principal problem that the outputs produced by liboctave need to be manipulated before they produce Matlab compatible results. That manipulation can either be in liboctave, or in libinterp/corefcn/gsvd.cc.

Thanks, I had to run "make maintainerclean".

I had to reclone
Dmitri.

Compiling with the current tip (e22906126af5), I get this error:
Do I have to do something extra for a successful compilation?

All done. I updated the list of unimplemented and merged to stable again. I also moved gsvd in the default branch to a new section of the NEWS file.

@Carnë: Could you do a merge of stable on to default? I just tried to do that to pick up a bunch of patches for gnuplot, but Mercurial wanted to delete gsvd on the default branch which was confusing.

No, just the unimplemented list. The spellchecker exception is so minor we can just leave it be.

> In this case, we don't have gsvd in Octave or in Octave Forge anymore.
The linearalgebra package hasn't been released in more than a year. The last release still has gsvd. Still, I reverted the removal of the function http://hg.code.sf.net/p/octave/linearalgebra
> There are still bits of gsvd left on the stable branch that need to be cleaned up. Also, it should go back on to the unimplemented list.
I can put it back on the unimplemented list. About the other bits left behind, I only see the exception to the spellchecker. Are you referring to that or am I missing something else?

I pushed a cset on the dev branch that prepares the gsvd function for implementation. It updates the docstring to refer to the API that will be implemented, not the existing one. I added input validation for a third input, for when "economysized" decompositions are implemented. The code was very old in using the deprecated error_state variable so I got rid of that in favor of the new xmatrix_value call. I added FIXME notes where more work has to be done. For example, I added a warning if the user has inputs of type single. Eventually that part of the code can be deleted when the connection to the single gsvd class is made. I added a simple BIST test taken from the examples in the Matlab documentation. All of the BIST tests are now tagged with the 48807 bug number so they won't cause failures to show up in 'make check'. See http://hg.savannah.gnu.org/hgweb/octave/rev/98eeed41f372.

Retitling report back to the original issue which is that the results are not Matlab compatible.

I don't think it's necessary to remove gsvd, as I stated. It's better in my opinion to have 75% of something rather than 100% of nothing. In this case, we don't have gsvd in Octave or in Octave Forge anymore.
But if you're keen to keep it in development for another cycle, okay. There are still bits of gsvd left on the stable branch that need to be cleaned up. Also, it should go back on to the unimplemented list.

Yes, it is usable but this is not the right fix. I think that if we didn't had the incomplete gsvd already in the repository and someone submitted as it is, we wouldn't accept it and would ask the submitter to do it correctly without those issues. But we still don't have to accept it. gsvd has not been released in any Octave version yet so we can just revert the changes and do it properly later.
This was my mistake, I should have tested gsvd better and check Matlab compatibility before merging. If it was not in the repo, and I were to add it now to core in this state, would it really be accepted?

The example cases and reference results in comments #6 and #7 above can be used for updated BISTs.

I also think like Rik that gsvd should not be removed.
The double/single issue can be treated with input validation until a proper fix will be made. But the commented out BISTs should be fixed before 4.2 release.

Why remove it? I think it's usable as is. The difference between single and double is something that could be taken care of in a bug fix release, 4.2.1. Or just add an input validation check to the mfile that emits an error if any of the inputs is single.
As for testing, the mfile approach passes the examples listed in the Matlab documentation. That's at least 4 tests.
I don't think anyone is going to start picking up the gsvd C++ code right away. In fact, I'm not sure that anybody really builds their own applications that link directly to liboctave, even though we have made it a possibility.

Three issues with this mfile wrapper:
1. the function still does not work properly if matrices are of class single (it's converting to double behind the scenes and returning the double).
2. there is still no tests to check that this fix actually fixes the issue.
3. the right fix would be in gsvd c++ class. If we delay the fix for 4.4, we will then have to deal with backwards compatibility on the gsvd class.
No one has been asking for this function, we just thought it would be a quick exercise for Barbara during GSOC so I don't think there's a big issue with delaying it until release 4.4 when it's done properly.
Now that default was merged into stable, I'm revertinf the mfile change on stable, merge that to default, and then removed gsvd completely for the 4.2 release.

I wrote an mfile wrapper for the C++ gsvd function so that it returns Matlabcompatible results (except for ordering of singular values which I wasn't too worried about). See this cset http://hg.savannah.gnu.org/hgweb/octave/rev/73a85c6cacd1.
Ideally, we need someone to translate the mfile hack into C++ code after the 4.2.0 release. Also, I commented out all of the BIST tests since they were based on the old behavior. Those need to be updated too.
The good news, though, is that 4.2.0 release can happen with gsvd included.

though if we remove gsvd, it should be restored to the linearalgebra package version intended for 4.2

I think jwe is going to release from the development branch, and then merge dev to stable. Given that, it would be best to remove it from the development branch and then reverse that after the release.

How are we dealing with this for the next release? I can push a commit that removes this code on the default branch and then revert it once 4.2 has been released. Or if the default branch is merged into stable for the release candidates, this could be undone only on the stable branch.

I won’t have time for it, I am overwhelmed with school.
Here is the result of Nir’s test cases in Matlab R2016a:

Can someone please run the following test cases in Matlab?

I have changed the order of the arguments to match what we would expect from Matlab (and reducing code duplication)
http://hg.savannah.gnu.org/hgweb/octave/rev/de24ca103c21
added support for float to liboctave gsvd (but did not make an interface to it on libinterp)
http://hg.savannah.gnu.org/hgweb/octave/rev/09005ac7d56c
and moved the class into the octave namespace as discussed some weeks ago on the mailing list
http://hg.savannah.gnu.org/hgweb/octave/rev/0aee8b620864
It's still needed:
 X, C, and S must be Matlab compatible (and the tests adjusted);
 support for class single from the Octave interpreter (with tests)
Nir or Barbara, can you do it? Without these very soon, I will remove them from the next 4.2 release.

It looks like there are differences between Matlab and LAPACK in how GSVD is defined. This is alluded to vaguely in both Matlab's [1] and Octave's [2] documentation.
An interface to LAPACK's GSVD routines is good to have available, regardless of what Matlab is doing.
As far as recovering Matlab's form, we can do that (up to the ordering of singular values and vectors, which seems to be consistently the opposite) for at least their Examples 1 and 2 with
[1] cf. https://groups.google.com/forum/#!topic/comp.softsys.matlab/aBgSZNTBcxU
[2] "Other authors, like S. Van Huffel, define this transformation as the simulatenous diagonalisation of the input matrices, this can be achieved by multiplying x by the inverse of [I 0; 0 r]."

Check the Matlab documentation (http://www.mathworks.com/help/matlab/ref/gsvd.html). They have a description of each output, and I simply tried Example 1 that was listed there.

There may be different definitions in use of the GSVD outputs. Can you post results from both Matlab and Octave for some cases, such as the examples in the documentation?

I assumed that the function in the linearalgebra package was compatible and it was only a matter of adjusting to fit into core build system.
From the docs, it would seem that it's only the order of the output values that is incorrect. Nir and Barbara should comment on this. The place to start would be making tests for those issues with Matlab that are failing now.

The newly introduced gsvd function in Octave has a different syntax and produces different results than Matlab (http://www.mathworks.com/help/matlab/ref/gsvd.html).
