Hello World!

Today I have my first post ever on the Numerical Method blog. I’d like to discuss a design decision when writing our library. This is to give our friends some insight into how the SuanShu library works. Please leave me feedbacks and comments so that we can continue to improve the product for you.

We have decided to make the class library as parsimonious as possible to avoid method pollution. This is inspired by the jMatrices’ white paper. The challenge is to organize the methods by minimal and correct packages.

I will illustrate this with SuanShu’s Matrix packages.

The `Matrix` class has only 26 methods, of which 9 of them are constructors and the related; 3 are overrides for the `AbstractMatrix` interfaces; 8 are overrides for the `MatrixSpace` interfaces. Only 6 of them are class specific to make calling these methods convenient for the user. The other dozens of matrix operations, such as the different factorizations, properties like rank, transformations like inverse, are grouped into multiple classes and packages. In most cases, each of these operations is a class on its own.

For instance, the inverse operation itself is a class inheriting from `Matrix`. The constructor takes as input a `Matrix` to invert. For example, to find the inverse for

,

we code

<pre>

Matrix A = new Matrix(new double[][]{

{1, 2, 3},

{6, 5, 4},

{8, 7, 9}

});

`Matrix Ainv = new Inverse(A);`

</pre>

SuanShu computes

It is important to note that `Ainv` is a `Matrix`, created by the keyword `new`, not by a method call.

*In summary, we choose to have 100s of classes, rather than to have a class with 100s of methods.* Each class is kept deliberately short. This class parsimony principle is a key design decision guiding the whole library development.

No comment yet, add your voice below!