Ted Dunning a écrit :
> On Thu, May 14, 2009 at 3:18 AM, Sam Halliday <sam.halli...@gmail.com>wrote:
>
>> I am a maintainer of the matrix-toolkits-java
>
>
> Which is an impressive piece of work, especially the transparent but
> non-binding interface to the Atlas and Blas native packages. My compliments
> to Bjørn-Ove and all who have followed up on his original work.
>
> This note is in regard to the commons-math library. It is clear that our
>> projects dovetail, especially when I look at "linear" in version 2.0 of the
>> API. It would be good if we could either complement or consolidate efforts,
>> rather than reproduce.
>
>
> That sounds good to me.
You are right.
>
> As a start, I'd like to discourage the use of a solid implementation for
>> SparseReal{Vector, Matrix}... please prefer an interface approach, allowing
>> implementations based on the Templates project:-
This is exactly the purpose of the RealMatrix/RealVector and FieldMatrix
/FieldVector interfaces on one side and of the CholeskiDecomposition,
EigenDecomposition, LUDecomposition, QRDecomposition,
SingularValueDecomposition and Decompositionsolver interfaces on the
other side.
RealMatrix (resp. FieldMatrix) is the top level interfaces that does not
mandate any specific storage. It has several implementations
(RealMatrixImpl with a simple double[][] array, DenseRealMatrix with a
block implementation, SparseRealMatrix). We also have in mind (not
implemented yet) things like DiagonalRealMatrix or BandRealMatrix or
Lower/UpperTriangularRealMatrix. All implementations can be mixed
together and specific cases are automatically detected and handled to
avoid using the general embedded loops and use smart algorithms when
possible. There was also an attempt using recursive layouts (with
Gray-Morton space filling curve).
Maybe SparseRealMatrix was a bad name and should have been
SimpleSparseRealMatrix to avoid confusion with other sparse storage and
dedicated algorithms.
>
>
> Can you say more about what aspects of the Templates project you feel are
> important? You mention one case of storage layout.
>
>
>> I believe commons-math should move to a netlib-java backend (allowing the
>> use of machine optimised BLAS/LAPACK).
>
>
> This is an interesting suggestion. Obviously adopting MTJ wholesale would
> accomplish that.
>
> Can you say something about the licensing issues if we were to explore, for
> discussion sake, MTJ being folded into commons-math? MTJ is LGPL while
> commons has to stay Apache licensed. This licensing issue has been the
> biggest sticking point in the past.
This is really an issue. Apache projects cannot use LGPL (or GPL) code.
See http://www.apache.org/legal/resolved.html for the policy.
[math] also has currently zero dependencies. We had two dependencies on
other commons components up to version 1.2 and removed them when we
started work on version 2.0. Adding new dependencies, and especially
dependencies that involve native libraries is a difficult decision that
needs lots of discussion. We are currently trying to have 2.0 published
very soon now, such a decision would delay the publication several months.
Some benchmarks I did a few weeks ago showed the new [math] linear
package implementation was quite fast and compared very well with native
fortran libraries for QR decomposition with similar non-blocked
algorithms. In fact, it was 7 times faster than unoptimized numerical
recipes, about 2 or 3 times faster than optimized numerical recipes, and
very slightly (a few percents) faster than optimized lapack with Atlas
as the BLAS implementation. Faster QR decomposition required changing
the algorithm so the blocked lapack implementation was the only native
implementation faster than [math]. Of course, I now do want to also
implement a blocked QR decomposition in [math] ...
I am aware that we still lack lots of very efficient linear algebra
algorithms. Joining efforts with you would be a real gain if we can
solve the licensing issues and avoid new dependencies if possible.
[math] has already adopted a lot of external code, even complete
libraries. I came in by donating the whole mantissa library, merging it
in and now contributing to the maintainance of the component with the
other developers.
Luc
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
