I see that some work has been going on for Matrices in corefxlab.
The code that we have there makes sense for some interesting scenarios, but it is not general enough. They are useful for 2D and 3D graphics mostly, but they are not general enough to support what is becoming quite popular, multi-dimensional arrays suitable for both linear algebra and machine learning. They are both limited on the dimensions and the data types support.
Our built-in arrays already provide the proper storage (single dimension, multiple dimensions, jagged) as well as the various types that are needed (floats, doubles, bytes, integers) and so on but lack various convenience operations to operate on them. Our built-in arrays are indeed suitable to be used for tensor storage that goes beyond the 2d matrices in the labs currently.
I believe the right approach is generally to extend the capabilities of Array with a combination of API improvements or language improvements (having C# for example support operator * (Array,scalar) where the operators would call into supporting library functions to do the heavy lifting (additionally, these can become JIT intrinsics).
Our multi-dimensional arrays already provide the necessary storage and API that would be suitable both for these matrix operations as well as the more general
The above would need to be extended for all the various operators (+, -, *, / and so on) as well as extend the language to accept the operators in the context where they make sense. The above example really should be operator * (int [] value, int scalar) extended to all the numeric data types. Other operations are also useful, like matrix multiplication which would operate on compatible multi-dimensional arrays.
Other operations belong on the class libraries, like filling up arrays with zeros, with ones, creating identity matrices and others.
Some inspiration can be taken from:
As well as NumPy:
https://docs.scipy.org/doc/numpy-1.12.0/reference/index.html
I am interested in this as my area is mostly finance. There are perf considerations on storage as memory access is often 80% + of matrix multiplication time. Anyway I am keen to help
https://github.com/cetusfinance/qwack/blob/master/src/Qwack.Math/Regression/MultipleLinearRegression.cs
@cdrnet do you have some suggestions for functionality you'd like to see us pull down into the framework so that we can do it better with JIT intrinsics?
I've been looking in this area myself and trying to understand what things make sense to bring into BCL vs let folks implement in domain-specific libraries. I see a lot of native ML libraries that just have language-specific bindings. Those wouldn't benefit from us doing much in the framework since they all operate on their own data-types anyway. I also see a really healthy project in Math.NET and wouldn't want to take anything away from that or cause confusion by duplicating things in the BCL.
I do see a need for folks to do some of these operations directly in .NET when preparing data to feed to native-ML or implementing ML libs directly in .NET (like @cesarsouza) but I had been thinking that those libraries would either prefer use a more full-featured implementation like Math.NET or implement operations themselves so that they can tune them. I'm also nervous about adding any sort of fad technology to the BCL that creates bloat for framework authors to implement and maintain.
I like the suggestion of simple matrix operations. These are not fad and definitely something we could do better with the JIT. I'd be interested in hearing other suggestions.
/cc @mellinoe @whoisj
Fused multiply add in vector would help
I don't think anyone is actively working with or using the matrix library in corefxlab. I think it is a "throwaway" library from a couple years ago -- there was some initial interest from a couple of contributors, but it died out without much design or iteration.
I don't understand the suggestion to allow arithmetic operators on array values, personally. Adding specialized methods in a library with the desired semantics seems like it would be more straightforward to me, and easier to explain / document. Using operators feels unusual.
As for exposing more intrinsics and making this stuff faster (however it is exposed): we have some plans around this and will most likely share some concrete proposals soon. There are various discussions around the repositories as well, for example: https://github.com/dotnet/coreclr/issues/6906
May also be interesting Essential Cheat Sheets for Machine Learning and Deep Learning Engineers (Python)
Most helpful comment
May also be interesting Essential Cheat Sheets for Machine Learning and Deep Learning Engineers (Python)