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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
