Vector as accessor into a Matrix


(Colin Green) #1

I see there’s a way of obtaining a Vector from a Matrx row or column, and that this copies the matrix elements. I was wondering if it would be useful to have a Vector subclass that uses the matrix row or column as it’s underlying storage?

Sometimes it’s useful (and makes for cleaner code) to define a function as operating on Vector rather than passing in a matrix and the index of the row/column to operate on. We can use Row() and Column() today, but that introduces the overhead of copying data.

Just an idea.

Thanks.


(Christoph Rüegg) #2

I fully agree on the second paragraph. The question is what you’d want to do with this vector “view” afterwards. It is quite straightforward to implement something like this in a lazy way, avoiding the copy, but would then perform quite poorly on vector-operations afterwards (no native providers, no efficient array routines etc).


(Colin Green) #3

I’m not especially familiar with the native providers but I get the broad point. There will always be compromises between design goals (e.g. performance and flexibility) and it’s perhaps a more difficult balance to find in managed languages/runtime, e.g. in C/C++ we could get a pointer to a matrix column and treat it as an array (which it is); we can do this in dotNET but that requires using the ‘unsafe’ compiler switch and pinned objects, so there’s already considerations there which you don’t have in the unmanaged world. And of course a row vector causes indirection in the accesses due to the column major ordering of the matrix, so probably just as well to copy in that case to obtain good CPU cache coherency (depending on how many accesses will be made on the vector)

Incidental, are you aware of the less than ideal performance in dotNET of multi-dimensional arrays compared to jagged arrays? One option is to use jagged arrays as matrix storage, but the issue there is (A) the storage is not guaranteed to be in a contiguous block, and (B) it’s optimising around what is arguably a fixable issue in the platform (the CLR, compilers and the framework classes).

On balance copying into vectors is probably the best approach. I was thinking that a vector view/window onto a column (i.e. in line with the column major ordering) would be nice in some cases, and that the performance for simple accessing would be OK if the getters and setters were all inlined by the JITter (assuming the inlining works over multiple levels/layers of s getters/setters).


(Christoph Rüegg) #4

Yes, that’s one of the reasons we use neither. For dense matrices we use normal 1D arrays. Working with such arrays is not only very efficient but also what makes our native provider approach possible (MKL, OpenBLAS, etc).

Btw, Math.NET Iridium, the predecessor of Math.NET Numerics, did use jagged arrays for matrices. But we didn’t have native providers back then.


(Colin Green) #5

For dense matrices we use normal 1D arrays.

Ahh OK, good to know - I somehow missed this when browsing through the code.

Regarding the vector view, there’s been a related discussion on the dotnet/roslyn project…

Proposal: Slicing #120

Thanks for your time.