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 (http://incubator.apache.org/hama) with ScaLAPACK members. On Thu, May 14, 2009 at 7:18 PM, Sam Halliday <sam.halli...@gmail.com> wrote: > > Dear all, > > I am a maintainer of the matrix-toolkits-java > > http://code.google.com/p/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:- > > http://www.netlib.org/templates > > 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 netlib.org 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). > > http://code.google.com/p/netlib-java/ > > 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: > http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23537813.html > Sent from the Commons - Dev mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Best Regards, Edward J. Yoon @ NHN, corp. edwardy...@apache.org http://blog.udanax.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
