commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Halliday <>
Subject commons-math, matrix-toolkits-java and consolidation
Date Thu, 14 May 2009 10:18:20 GMT

Dear all,

I am a maintainer of the matrix-toolkits-java

which is a comprehensive collection of matrix data structures, linear
solvers, least squares methods, eigenvalue and singular value

This note is in regard to the commons-math library. It is clear that our
projects dovetail, especially when I look at "linear" in version 2.0 of the
API. It would be good if we could either complement or consolidate efforts,
rather than reproduce.

It would be excellent if all the functionality of matrix-toolkits-java were
available as part of commons-math. There is already too much diversity and
un-maintained maths code out there for Java!

As a start, I'd like to discourage the use of a solid implementation for
SparseReal{Vector, Matrix}... please prefer an interface approach, allowing
implementations based on the Templates project:-

The reason is that the storage implementation should be related to the type
of data being stored. For example, there are many well-known kinds of sparse
matrix that are well suited to particular kinds of calculations... consider
multiplying sparse matrices that you know to be diagonal!

In general, the folk (BLAS/LAPACK) have spent a *lot* of time
thinking about linear algebra and have set up unrivalled standard APIs which
have been implemented right down to the architecture level. It would be a
major mistake if commons-math didn't build on their good work.

I believe commons-math should move to a netlib-java backend (allowing the
use of machine optimised BLAS/LAPACK).

The largest problems facing MTJ are support for Sparse BLAS/LAPACK and
scalability to parallel architectures which use Parallel BLAS/LAPACK. The
former should be possible with some work within the current API, but I fear
major API changes would be needed for the latter. I do not want the
commons-math API to walk into this trap without having first considered
future architectures! MTJ has a distributed package, but I am not sure if
this is something that is completely future proof either.

What say ye'?


View this message in context:
Sent from the Commons - Dev mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message