This project has moved. For the latest updates, please go here.

Use of expression objects instead of containers in arithmetic

Aug 14, 2011 at 3:03 PM

Hi,

Sorry if this is a consequence of misreading code or missing older discussions. But:

Considering that you might have large complex matrix expressions of the kind:

var RES = A*B+C*D+E*(.....)

It looks like that every sub-expression generates a new container of the right type instead of an "indexed expression" that is capable of generating the right elements.

In case I'm right in my observation, wouldn't it be better performance-wise to let ie. A*B (and friends) return some object that is an object, that can generate A*B(i,j) for each index pair (i,j) instead of a full temporary matrix. Or is my conclusion arcane and from the old days where we tried to reduce usage of temporary heap storage?

Regards,

Michael

Coordinator
Aug 14, 2011 at 3:07 PM

Hi Michael,

Thanks for your question. Math.Net numerics currently tries to be a library which implements numerical algorithms. I think your suggestion is a very good one for a more thorough scientific computing environment or perhaps a symbolic computing package but it is a bit more high level than we are trying to provide.

Cheers, Jurgen

Aug 14, 2011 at 3:42 PM

Hi Jurgen,

Thanks for clarifying. I'm unable to figure out what's smartest - have my own old packages, that I've been rewriting since the nineties, mostly targeting dynamical systems and the (numerical) analysis thereof. Since the first old papers about expression templates in C++, I've put it into my drill always to have stuff like:

public static DoubleIndexedExpression<T> operator +(Matrix<T> x, IDoubleIndexedExpression<T> y) 
{
   return new Add<T>(x.AsExpression(), y);         
}

even in my .NET code, that is a simple shallow object that is just taking its place in the object hierarchy being implicitly built up. In the old days, creating objects on the heap was a very expensive operation, involving process locks etc, but I don't know whether it's worthwile today, since the CLR is fairly different. Could've been fun to check out. It requires a lot of small arithmetic helper classes though.

Michael

Coordinator
Aug 14, 2011 at 4:16 PM

Thanks for clarifying. I've seen a few proprietary .NET packages that take a similar approach. At the end of the day, they try to compile into fast numerical procedures which is where I think Math.Net would fit in.