Any chance of creating extension methods that act directly on float[] instead of using Vector<float> ?

[pengowray]

I'm largely using the Vector<float> class, but it seems very inefficient to creating DenseVector objects just to turn them back to float arrays (e.g. for compatibility with other libraries that I need to use). Have there been any thoughts on creating a set of extension methods which contain all of Vector's methods, for manipulating float[] and double[] arrays more directly using extension functions?

I'm sure I can't be the first to suggest this. If this already exists please let me know. Otherwise I might attempt to convert MathNet.Numerics.LinearAlgebra.Single.DenseVector into a little library of extension methods for myself (as that that has most of the methods I need), but I'd rather not maintain a math library myself.

Cheers

[cdrnet]

There are multiple parts to this:

• A lot of the routines are calling our provider abstraction (ILinearAlgebraProvider) which operate directly on arrays. Although I do not recommend it, you can use them directly (see Control class). Let me know if you miss some routines there, we can extend them if appropriate.
• The choice of wrapping the arrays into small (and comparably cheap) types as primary API is a fundamental and well reasoned design choice. There are currently no plans to move away from this approach.

Note that other libraries indeed made different design choices, e.g. Accord.NET provides vector routines directly on top of arrays.

[pengowray]

Thank you for the reply.

I did not mean to suggest that the API should shift to using extension methods instead of the current well-reasoned design choice of using wrapped arrays. The current style allows abstractions and optimizations that plain arrays would not lend themselves to. For example, it lends itself to interchangeability of dense and sparse arrays. Rather, the suggestion was to add extension methods as another option for the user, for scenarios where it would be appropriate, such as for optimization or where the user does not want to fully commit to switching their code over to fit the Math.NET Numerics framework.

I have been experimenting and found a significant speedup (25%+ faster) in one of my tests for my particular scenario simply by shifting to manipulating DenseVectors rather than dealing with the more abstract Vector type, as it allows peeking into the underlying array (DenseVector.Values) rather than copying them with .ToArray(). It complicates things, however, as math functions return Vectors, not DenseVectors and I'm stuck with having to cast back to DenseVector (with checks for type), or revert to ToArray(). There's got to be a better way.

I understand the motivation for using abstraction and data hiding. However, in my case it creates significant overhead. Again I'd suggest extension methods on float[] (and double[]) as a solution. Float arrays create no illusion of hidden, immutable, or abstract data, and no unnecessary overhead of casting or ToArraying. Perhaps the library could simply automatically wrap them into a DenseVector when the code gets too hairy, or when calling methods that haven't don't have versions for working directly on arrays yet.

Anyway, that's my suggestion, and I think it would be allow Math.NET Numerics to be a drop-in solution in any project that needed vector math, rather than currently where there is much more friction than necessary to begin using it.

Thanks for the the suggestion of Accord.NET. I've looked at it previously, and it would seem to be an appropriate library, especially as it includes machine learning algorithms (appropriate to my field). Except that it largely only deals with [suboptimal for me] double-precision floating-points (which is odd as neural nets can generally run perfectly well even on 16-bit half-precision floats, and this library includes NN code). Also, I have the impression that Math.NET Numerics more broadly covers more general operations, and that the algorithms in Math.NET Numerics are more tightly optimized on the algorithm level and for parallelization, though I haven't directly compared their output of the two and have only briefly scanned the code.

I'm a somewhat disappointed that I couldn't find a generic math library that would allow simply vector math operations on float[] style vectors, and this library seems to be the best candidate I could find for adding that functionality if anyone was to do it.