
Boost : 
From: Hayati Ayguen (Ayguen_at_[hidden])
Date: 20010820 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 Cstyle 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
> > "mtl3" 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.2xx 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk