commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [math] linear algebra enhancements rise issues
Date Sun, 24 Aug 2008 22:14:59 GMT
Luc Maisonobe wrote:

Sorry for the "slow" response, Luc. 
> Hello,
>
> I am currently working on several enhancements for the linear algebra
> package, related to issues http://issues.apache.org/jira/browse/MATH-157
> and http://issues.apache.org/jira/browse/MATH-220.
>
> For now, I have added solve methods in
> QRDecomposition/QRDecompositionImpl and copied
> LUDecomposition/LUDecompositionImpl from RealMatrixImpl in an almost
> JAMA-compatible style. I will work on
> SVDDecomposition/SVDDecompositionImpl soon.
>   
Thanks!
> I have two issues now.
>
> The first issue is related to LUDecomposition. I would like to
> completely remove the corresponding code from RealMatrix, taking the
> opportunity of a major version release since it breaks compatibility. We
> already choose to broke compatibility in several aspects for this
> release. Does this move seem acceptable to everybody ?
>   
Can we deprecate and delegate functionality instead of removing?
> The second issue is related to BigMatrix. I have mixed feelings about
> this class. It seems either too much or not enough. It is highly
> specialized towards one use case (high precision at the cost of
> slowness, as explained in the original post from 2004
> http://markmail.org/message/bvus3dbihgmewtw4) but induces many code
> duplication. Implementing QRDecomposition, LUDecomposition,
> SVDDecomposition ... is possible, I will most probably do it once the
> important native double implementations are frozen.
>
> However, I am looking at another way to do this bearing more use cases.
> What about a more generic approach with a Field interface ? This has
> been discussed and rejected in 2003
> (http://markmail.org/message/otkcmoqixierewsz), but now we have switched
> to Java 5, we already have a BigMatrix class, and we still have the
> RealMatrix implementation for common cases as expected by the vast
> majority of users. We also now have a more advanced library and can
> think to extend some parts. What I would propose is to still have two
> implementations: RealMatrix and FieldMatrix. The first one would
> probably be used by most users, but the second one could also be used
> for some specific needs, one of which is increased precision (we would
> need a simple wrapper class to adapt BigDecimal to our Field interface),
> another one is Complex computation, still another one is interval
> arithmetic, or even differentiation (yes, I think about Nabla and
> DifferentiablePair here).
>   
Sounds reasonable.  As long as we keep the fast, native impl for most 
applied uses, I am OK introducing FieldMatrix. 
> Here is the work involved:
>  - refactor BigMatrix into FieldMatrix
>    this is a simple task I think.
>  - implement the decomposition classes for FieldMatrix
>    doing this for Field or BigDecimal is the same amount of work
>  - design the Field interface
>    this is straightforward for most methods (add, multiply, subtract,
>    divide, negate ...). I'm still not sure how to handle the two neutral
>    elements (ZERO and ONE) since we cannot specify static methods in an
>    interface (or am I wrong ?).
>  - design an extension of the Field interface with support for sqrt
>    this may be needed by some algorithms
>  - refactor Complex to implement the extended Field interface
>    this is trivial and would allow us to support complex matrices as an
>    almost free by-product.
>  - refactor Fraction to implement Field interface
>    this is trivial too
>  - create an adaptor for BigDecimal
>    this is trivial too
>
> Of course, if this proposal is accepted, I will do this work.
>   
+1 assuming you are up for it.  I would also be OK postponing this to 
2.x and just deprecating BigMatrix in 2.0.

Phil
> Luc
>
>
> ---------------------------------------------------------------------
> 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