You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <Lu...@free.fr> on 2008/08/21 23:11:00 UTC
[math] linear algebra enhancements rise issues
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.
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 ?
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).
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.
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] linear algebra enhancements rise issues
Posted by Phil Steitz <ph...@steitz.com>.
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