I tried using Colt to replace invoking Matlab through a ProcessBuilder,
for computing truncated singular value decomposition. At least in my
test cases, for anything other than tiny matrices, the Matlab strategy
was faster. Part of the issue may be that Matlab implements a very wide
range of algorithms, including specific support for truncated SVD on
sparse matrices. The only way I could find with Colt was to compute the
full SVD and ignore the extra data.

From my point of view, there is still work to be done.

Oddly enough, the Matlab strategy is also logistically simpler, because
Matlab is installed on every computer on which I have any interest in
running my application, including computers I don't administer.

Patricia

Thanks for all the input,

I wish I could believe it is just a solved problem and that activity
isn't needed.

There are some very mature libraries in C and Fortran which change
very little.  However, they are very complete and have active user
communities.

The Java libraries I've found are incomplete (by reading their to-do
list and list of unimplemented features), and the communities are
ghost towns.  None of them appear to have reached the maturity of a
product in deep-maintenance-mode.

I think a better comparison is C++ (OO, younger, language still
changing, etc).  There are a great number of libraries under active
development, with vibrant communities.

Someone said language changes don't push library updates.  I agree
that they do not require it, but they do give opportunity for
advances.  The changes to the concurrency library in JSE5 are
significant enough to warrant revisiting the threading in existing
libraries, or possibly new libraries to exploit new techniques.  There
is a C++ library (http://www.oonumerics.org/blitz/) which exists
purely to take advantage of advances allowed by the introduction of
Template programming in C++.

This of course ignores the simple fact that numerical methods is an
active research area.  There are always new things to be done.  It may
be that researchers in the field still choose to do their new work in
Fortran, C, and C++ rather than Java.

             Rob