The number of interfaces cause many edge cases about matrix

[kortschak]

Alternatively, all of the interfaces could be folded into Matrix, so that all Matrixes would have to implement Col, and Row, and etc. That would be easier if goblas was always on.

This will not happen. Please see the original discussion around the API design.

[btracey]

For example, you may have a Matrix where it is possible to get individual elements, but it is not possible to store any particular Row in memory.

[kortschak]

At the moment I think the most Go-like approach is to write a MakeVectorer(Matrix) Vectorer func. This is easy to write and has minimal allocation costs. This func can then be used to wrap non-Vectorer matrices. Then either Vectorer-needing funcs can have their signatures changed or there can be a call to MakeVectorer internally (the func could be then made unexported).

[btracey]

I wonder if the package is too object-oriented at the moment, for reasons that @jonlawlor mentions. It can be hard to perform operations on abstract matrices. In some cases, this is a good idea (the signatures of Add and AddSym are different for a reason), but in other cases, like Col, it doesn't seem to be.

An alternate proposal would be the following: A specific functionality is a method if, and only if, it does one of the following:

1. Implements a package-level interface (i.e. the methods of Matrix)
2. Modifies the values in the receiver (many of the arithmetic operations)
3. Exposes data that could modify the value of the receiver (RawRowView)
4. Involves data specific to the matrix class.

If the functionality does not fit into one of those categories, it is a package-level function, taking in a Matrix (or a specific matrix class).

Here's what I see based on the current methods of dense. Number is the category under which it falls, F means will become a function. Specific other cases.

Add - 2
Apply - 2
At - 1
Augment - 2
Caps - 4
Clone - 2
Col - F
ColView - 3
Copy - 2
Dims - 1
DivElem - 2
Dot - F
Equals - F
EqualsApprox - F
Exp - 2
Grow - 2
L - Should be a method on Triangular
MarshalBinary - 4 (marshaling in general will be implementation dependent)
Max - F
Min - F
Mul - 2
MulElem - 2
Norm - F
Outer - 2
Pow - 2
RankOne - 2
RawMatrix - 3
RawRowView - 3
Reset() - 2
Row - F
RowView - 2
Scale - 2
Set* - 2
Solve* - 2
Stack - 2
Sub - 2
Sum - F
T - 1
TCopy - 2
Trace - F
U - Should be a method on Triangular
UnmarshalBinary - 4
View - 2

[btracey]

This proposal would, for example, decide #159 and help to fix #138 .

[kortschak]

SGTM

[btracey]

Fixed!