Luc, if the Apache team are happy to include source generated by f2j (which is therefore BSD license) then there is no reason at all to have a dependency!
The generator code from netlib-java need not be distributed as part of the final commons-math binary, it is only needed to generate the .c files which allow for a native library at runtime. I would foresee the .c files being distributed as part of the commons-math binary download, with instructions on how to build the optional native library. The entire mechanism for doing this is entirely up for debate and review. The important thing is that there be a standardised BLAS/LAPACK API available. Luc Maisonobe wrote: > > 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 > > > -- View this message in context: http://www.nabble.com/commons-math%2C-matrix-toolkits-java-and-consolidation-tp23537813p23575419.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
