Re: [boost] Re: Standard Matrix interfaces

From: Hayati Ayguen (Ayguen_at_[hidden])
Date: 2001-08-20 08:20:11

helmut.zeisel_at_[hidden] schrieb:
> 
> --- In boost_at_y..., Hayati Ayguen <Ayguen_at_b...> wrote:
> >
> > Many aspects have to be considered when implementing efficient
> > matrix/vector classes. i'm unsure about development status of all
> the
> > matrix class libraries out there, but i haven't seen any library
> > concerning all issues.
> 
> Exactly.
> However, if we wait for a matrix library that covers
> all these issues, we will never have a standard C++ matrix interface.
> 
> >
> > some of the important issues are:
> ...
> >
> > i'm sure i forgot some important issues, so its to you to complete
> this
> > list!
> >
> 

one of the forgotten issues are strides and submatrices.

> IMHO, what is needed most is a simple
> interface for rectangular, dense matrices,
> covering C-style layout.
> In a first step no operators, no expression templates,
> no transpose etc.

especially sparse matrices need access methods/iterators to the elements
of a matrix. declaring a too simple interface supporting only
rectangular, dense matrices is wrong. such a standard interface would
lead many people to write higher level code (matrix solver ...) for such
an interface. but you'll have to rewrite / throw away such code if other
issues require a new more sophisticated interface solving element access
in a more uniform manner.
all current issues have to be taken into account for specifying such an
interface.

i agree that we don't have to implement anything like operators,
expression templates, transpose, ... but we need proper interfaces for
such functions. take transpose() for example:

a) should it be a global function where
   Matrix A;
   Matrix tansposed_mat = transpose( A );
b) a static member function
   Matrix A;
   Matrix tansposed_mat = Matrix::transpose( A );
c) a member function modifying itself
   Matrix A;
   Matrix tansposed_mat = A;
   transposed_mat.transpose();
d) .. ?

or take a simple addition:
a) global
   add( const Matrix& op1, const Matrix& op2, Matrix& op1res );
b) static member ...
c) or change the ordering of the arguments:
   add( Matrix& op1res, const Matrix& op1, const Matrix& op2 );

or how to address heteregeneous operations:
add( Vector<double>& op1res, const Vector<int>& op1, const Vector<int>&
op2 );
   is it satisfactory to calculate internally with:
      double = int + int;

and how about
divide( Vector<double>& op1res, const Vector<int>& op1, const
Vector<int>& op2 );
or call it div()
.....

all this has to be considered!

> This is the minimum to get a standard interface
> for an OO usage of many legacy C libraries like IMSL.
> 
> Every more sophisticated C++ library
> should follow the same basic interface,
> but clearly may add additional special purpose methods.
> 
> > i'm also unsure of how many of the above issues are concerned in the
> > "mtl-3" which is mentioned to get part of boost.
> >
> 
> What is the actual state of MTL 3?
> If it is far enough, it might be a good idea
> to use the interface of MTL 3 as a basic matrix interface.

i don't know the status of MTL3 but MTL 2.1.2-xx can be found at
http://www.lsc.nd.edu/research/mtl/

> 
> > A cooperation with OON
> (http://www.oonumerics.org/oon/)
> > group should be considered.
> >
> 
> I agree.
> But anyway, the emphasis of OON is more on implementation,
> while IMHO the emphasis of boost should be on interface.
> 
> Helmut