.NET Opensource

I have done some qualitative tests comparing different array types as storage for a Matrix class and have found that the rectangular array is the slowest possible way to implement the Matrix class.  The other two options that I considered where jagged arrays (double[][]) and linear arrays(double[]) where the index was calculated by the class.  Of those two, there was not a consistently better implementation in the tests I executed, but the jagged array seemed to be the better of the two, especially for readability of code.  If you would like, I can gather the results of the tests in a program that could be run by others.

I had the time tonight to go ahead and make the changes I am suggesting to a local copy of the class and run some tests.  I compared the performance of the original class and my modified version across most of the operations that did not involve a decomposition.  Here are the relative performances of each of the operations (time for modified / time for original).  I executed each of the operations 500 times, ignored the first time (because of JIT compile time), and calculated the average time for each operation.  The matrices used were square matrices generated by the Matrix.Random function.

Hi,

Thanks very much for your analysis. Your numbers speak a clear language. Interestingly I had just talked with another user about using jagged arrays instead of the rectangular ones some days ago...

Looks like we'll have a new matrix base in the next iridium release :)

Thanks,
Chris

PS: Are you interested in contributing to the codebase?

After making my original posts, I realized that switching to jagged arrays would potentially break code that uses these two functions of the Matrix class: 

public Matrix(double[,] A)
public static implicit operator double[,] (Matrix m) 

In my opinion, the best option for the implicit operator would be to make it return a double[][] instead, which would force consumers to rewrite their code accordingly.  A constructor for two dimensional arrays seems appropriate to keep, but consumers of the library would need to be informed of the change in semantics.  For example, the following code would produce differing results:

//assuming test is a double[,] and all indices are valid
test[4,3] = 2;
Matrix testMat = new Matrix(test);
test[4,3] = 3;
Console.WriteLine(testMat[4, 3])

In the current code this would print 3, but in the new code this would print 2. Also, I would be willing to contribute to the codebase, starting with a new Matrix class.

Gideon

I've submitted some changes on the matrix class (and dependencies) today, so it now uses jagged arrays, as you suggested. Indeed, I observed nearly 50% perf improvement on the included small Solve perf analysis project.

You may want to have a look at the changes first before updating your local SVN checkout, because it will most likly conflict with most of your changes. Did you follow a similar approach or is there a major difference?

I agree, we should inform about the change in semantics. Note, in my submit I also changed the implicit operator to explicit, but that was a mistake (idea was to prevent byzantine-kind of errors by forcing a break, but I was wrong); I'll most probably change it back to implicit.

On the constructor part I think we should make people who want to initialize with rectangular arrays (e.g. because it's more readable in code, or for interop with existing code) use the static Create method instead, since the Create methods always do a deep-copy, while constructurs should not. That's why I added the Obsolete-attribute to that constructor and intend to remove it completely in some future version.

Let me know what you think about the changes and how they compare with your ideas..

Thanks,
Chris