commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] linear algebra decomposition algorithms (SVD, Cholesky, QR, LU, eigen values ...)
Date Sat, 14 Jun 2008 18:40:02 GMT
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.


> Phil

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

View raw message