commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] linear algebra decomposition algorithms (SVD, Cholesky, QR, LU, eigen values ...)
Date Sat, 14 Jun 2008 20:01:52 GMT
Phil Steitz a écrit :
> Phil Steitz wrote:
>> Luc Maisonobe wrote:
>>> One of the task scheduled for 2.0 is the implementation of the Singular
>>> Value Decomposition.
>>> I think this addition should be done together with several other
>>> decompositions in a consistent scheme. What we have currently is:
>>>  - LU decomposition embedded directly into [Real/Big]MatrixImpl
>>>    without any reference to it in the [Real/Big]Matrix interfaces
>>>  - one QR decomposition as
>>>     1) an interface which is really only a way to retrieve results
>>>     2) an implementation which performs the decomposition on RealMatrix
>>>  - another QR decomposition hidden in the Levenberg-Marquardt estimator
>>> An API for these tasks was proposed by MathWorks and NIST with the JAMA
>>> package ( This package provides
>>> specific classes for the decomposition (LUDecomposition, QRDecomposition
>>> ...). These classes provide accessors for the elements of the
>>> decomposition (say L and U) but more importantly they provide methods to
>>> use the decomposition: a solve method for LU, QR and Cholesky for
>>> example. Jama has been widely used but is dead now (see for example
>>> The code is
>>> in the public domain.
>>> I would propose to roughly follow Jama API, probably adding interfaces
>>> on top of the decomposition classes to be consistent with our other
>>> algorithms, and using the public domain Jama code as a basis. We could
>>> also address simply the issue about SVD in the original message.
>>> The changes in our code would be to extract LU from the XxxMatrixImpl
>>> classes, to add new methods to the QR interface and to see how the
>>> Levenberg-Marquardt algorithm can use this (I think this last step is
>>> the most difficult, as the QR decomposition used there is slightly
>>> distorted).
>>> What do you think about it ?
>> I like this idea, with the following considerations.
>> 1) The LU decomp embedded in RealMatrixImpl was not made public or
>> included in the RealMatrix API precisely because I thought it would
>> eventually be externalized.  So far so good.  The thing I want to make
>> sure of is that the efficiency gain from caching it is still available
>> to RealMatrixImpl.
>> 2) I have always liked (well, mostly liked) the JAMA API and at one
>> point we talked about just incorporating a whole lot of JAMA code
>> directly into [math].  There are two reasons to be careful with this. 
>> The first is public domain does not necessarily mean unencumbered
>> (somewhat bizarely, but IANAL).  The second is support.  We need to
>> really understand how the code works to be able to support it.  For
>> these two reasons, I am +1 on borrowing from the API, but would prefer
>> clean room implementations of the *algorithms* that are implemented. 
>> It is OK to get ideas from the code, but I would prefer to develop the
>> implementations here or get them from authors who contribute directly
>> under ASF CLAs.  I guess if we really, really want to take some of the
>> code directly, we could go to legal-discuss, talk to the authors,
>> etc.,...
> I went back and found the previous discussion of JAMA.   Here is the
> legal-discuss thread, which is sort of inconclusive.

Thanks for the link.

I will try to develop clean room implementations for theses algorithms.


> Phil
>> Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message