commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Date Sat, 16 May 2009 16:40:28 GMT
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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message