commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Sterijevski <gsterijev...@gmail.com>
Subject (MATH-608) Remove methods from RealMatrix Interface
Date Fri, 01 Jul 2011 14:36:06 GMT
Hello All,

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.

-Greg

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message