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 netlib.org > 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 netlib.org'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 netlib.org, 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 > > > 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
