Sam Halliday a écrit : > 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!
Fine. > > 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. Yes. However, as both Phil and I have said, we still want to have 2.0 out very soon. Adding a complete BLAS API is a huge task so I really prefer to wait after 2.0. We can discuss about it here, of course. You could also open a JIRA issue for requesting the enhancement, targeting 2.1. Thanks Luc > > > 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 >> >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
