Fri Nov 7 17:36:34 2014, comment #1:
TL;DR I've attached a patch to bring `squareform' into line with MatLab. With this patch, it tests arguments and returns a row vector (when appropriate).
The lack of argument testing in the current `squareform' creates problems with both vector and matrix input. Currently, `squareform' doesn't complain if the input matrix fails to match the requirements of a distance matrix: a square symmetric matrix with zeros along the diagonal. For example,
`squareform([1,2,3; 4,5,6; 7,8,9])' returns
4
7
8
When `squareform' is asked to convert a vector `x' to an n by n matrix, it finds the value of n by solving the quadratic equation n^2  n  2k = 0, where k = length(x). Because the current `squareform' does no error checking, it is possible for `n' to take noninteger values. The function `zeros' which creates the matrix strips off nonintegers without displaying an error. This can lead to unexpected results in the returned matrix. For instance,
`squareform ([1,2,3,4])' returns
0 1 2
1 0 3
2 3 0
In both the above cases, MatLab's `squareform' returns an error and aborts computation.
Since the most recent maintainer of `squareform' stepped down in 2011, I have attached a patch for these issues. My patched `squareform' converts matrices to row vectors instead of column vectors. It also checks for incorrect input types, matrices with an incorrect format, and vectors of an invalid length. The MatLab description for `squareform' states that the routine requires a symmetric matrix. However, MatLab 2013b does not throw an error when a nonsymmetric matrix is used as input. To maintain compatibility with existing MatLab code which may rely on this lapse, when a nonsymmetric matrix is encountered by my version of `squareform', it gives a warning (which the user can choose to turn off).
The patched `squareform' also includes minor formatting changes to bring the code more into line with Octave's current recommendations.
(file #32389)
