commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward J. Yoon" <>
Subject Re: commons-math, matrix-toolkits-java and consolidation
Date Fri, 22 May 2009 02:14:32 GMT
That's really cool.

BTW, Can I ask about the plan of data distribution strategies of your
'distributed' package in the future? IMO, it seems, it doesn't sit
well with 'common-math' project.

If if there is a developer who wants to implement 'distributed', pls
let us know, too. I'm working for the Hama
( with ScaLAPACK members.

On Thu, May 14, 2009 at 7:18 PM, Sam Halliday <> wrote:
> 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
> decompositions.
> 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'?
> --
> Sam
> --
> View this message in context:
> Sent from the Commons - Dev mailing list archive at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Best Regards, Edward J. Yoon @ NHN, corp.

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

View raw message