commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: (MATH-608) Remove methods from RealMatrix Interface
Date Sat, 02 Jul 2011 02:28:56 GMT
On 7/1/11 4:26 PM, Gilles Sadowski wrote:
> Hi.
>
>> Luc suggested that I move this discussion to the list. Luc posed the
>> question:
>>
>> "I don't understand how you intend to separate the API.
>> Would that mean users would always have to know beforehand the shape of the
>> matrix they use and manage both the matrix, the data store and the operators
>> in sync ?"
>>
>> I think my longwinded report was not as clear as it should have been. I want
>> to simplify the RealMatrix interface and implementing classes. In my mind's
>> eye, I see the real matrix interface as describing the shape of the data,
>> holding that data and giving the user an indexing scheme to get at an
>> element.
>>
>> My concern with the current interface is that if different shapes of
>> matrices are allowed (Diagonal, Symmetric, Triangular, Banded) the matrix
>> manipulation routines (add, subtract, mult, ...) become very complicated.
>>
>> In my proposal, I argue that we might have another class, say
>> MatrixOperations.
>>
>> It would have routines for Mutlitplication that depend on type. A small
>> subset of the interface might look like:
>>
>> public interface MatrixOpsIface{
>>     public SymmetricMatrix selfTimesTranspose( SymmetricMatrix sm );
>>     public SymmetricMatrix selfTimesTranspose( GeneralMatrix sm );
>>     public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
>> GeneralMatrix gm);
>>     public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
>> SymmericMatrix sm2);
>>     public SymmetricMatrix sandwichProduct( SymmetricMatrix sm,
>> SymmetricMatrix gm);
>>     public GeneralMatrix multipy( DiagonalMatrix dm, GeneralMatrix gm);
>>     public GeneralMatrix multiply( SymmetricMatrix sm, GeneralMatrix gm);
>>     public DiagonalMatrix multiply( DiagonalMatrix dm, DiagonalMatrix dm);
>> }
>>
>> The benefit of doing this would be that you could write highly optimized
>> multiplication routines dependent on the shape of the matrices. All of the
>> complexity would be handled by the compiler. The user would simply
>> instantiate the operations object (maybe these could be static methods), and
>> call multiply. Adding a new matrix shape would be require an two check ins,
>> the code for the new matrix as well as a new set of methods for handling
>> multiplication, etc, with the other types.
> The idea of separating the algorithms from the storage layout sounds nice
> but why would a class implementing "MatrixOpsIface" be more performant, or
> simpler, than adding specialized "mutliply" methods within the RealMatrix
> implementations themselves?

+1

IIRC, we used to have a MatrixUtils class that encapsulated
RealMatrix operations, but we decided in this case (and for Complex)
to re-integrate.   I am not (yet) sold on the proposition that
splitting things back out does anything more than just move the problem.

> E.g.
> ---CUT---
> public class Array2DRowRealMatrix {
>   public Array2DRowRealMatrix multiply(Array2DRowRealMatrix m) { /* ... */ }
>   public Array2DRowRealMatrix multiply(DiagonalRealMatrix m) { /* ... */ }
>   /* ... */
> }
> ---CUT---
>
> Also, there seems to be the problem of exposing the internals (storage
> layout) so that the implementations of "MatrixOpsIface" can actually make
> use of them. This would break encapsulation: The layout would becomes part
> of the interface.
>
> Still, publicizing the operators might be interesting. With generics:
> ---CUT---
> interface Multiply<M extends RealMatrix,
>                    O extends RealMatrix> {
>     public O multiply(M m);
> }
> ---CUT---
>
> Hence, we advertise which operations are type-optimized:
> ---CUT---
> public class Array2DRowRealMatrix
>     implements Multiply<Array2DRowRealMatrix, Array2DRowRealMatrix>,
>                Multiply<Array2DRowRealMatrix, DiagonalRealMatrix> {
>     // ...
> }
>
> Sorry, if this is all besides the point; without a concrete example, it's
> difficult to figure what must be improved.

Agreed.  I think its best to look at the actual practical examples. 
Above idea is interesting.  Will it solve your problem, Greg?

Phil
> Also, you could have a look at
>   http://www.ojalgo.org
>
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> 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