commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Date Sat, 16 May 2009 15:43:46 GMT
Sam Halliday a écrit :
> I've somehow missed much of this discussion, which has got a little confused.
> I'll repeat some key facts here:-
> - MTJ depends on netlib-java
> - I'm the maintainer of netlib-java
> - netlib-java depends on PURE JAVA code, generated by F2J from
> BLAS/LAPACK (and ARPACK). Keith Seymour (author of f2j) deserves all the
> praise for that magnificent task! The necessary jar is distributed with
> netlib-java.
> - BLAS/LAPACK are industry standard APIs.
> - netlib-java is technically a "translation" of's
> BLAS/LAPACK/ARPACK API, so is therefore BSD licensed
> - netlib-java can be *optionally* configured at runtime to use a native
> library instead of the Java implementation.
> - the java implementation is pretty damn fast and will be more than adequate
> for most users. However, it will *never* be as fast as native code running
> on specialist hardware (no matter how much the JVM improves).
> Being the maintainer of netlib-java, I'd be more than happy to re-license
> all the bits that aren't technically "translations" of, for
> inclusion in commons-math (in fact, it makes sense to do so). But you'd
> still need to depend on the f2j translated implementation. They are BSD
> license.

This is becoming more and more interesting. However, do yo think it
would be possible to "include" the source (either manually written or
automatically translated) into [math] ? This would allow a
self-contained package.

We already provide some code which technically comes from translated
netlib routines, for example part of the Levenberg-Marquardt or almost
everything in the singular value decomposition. The Netlib license
allows that and we have set up the appropriate notices (see the javadoc
and the NOTICE.txt file).

> Hell, it makes a *lot* of sense for commons-math to provide the BLAS/LAPACK
> API... they are industry standards after all, and all reference
> implementations for linear algebra algorithms make use of them.

I strongly approve that for BLAS. I dream of the BLAS API being
mandatory in JVM implementations, but this will probably never happen.
Considering LAPACK, I am less convinced because the API is strongly
fortran-oriented, not using some of the object-oriented features that
are well suited for mathematical concepts. The algorithms and their
implementations are very good, and we already use them inside, but with
a different API.


> Luc Maisonobe wrote:
>> I have an additional reason for avoiding native libraries. Pure Java can
>> be processed by external tools for either inspection (think findbugs,
>> cobertura, traceability, auditing) or modification (think Nabla!). The
>> Nabla case is especially important to me, but I am aware this is a
>> corner-case.

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

View raw message