Boost logo

Glas :

[glas] Re: GLAS requirements

From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2004-12-30 06:54:35


Hi,

I have a few comments to add the the general framework that Toon
submitted last week.

To the views, we should add a matrix element. This is important, because
for structured and sparse matrices, element access requires some
thinking (for those familar with ublas: recall the discussions on
element proxies in the sparse case). In other words, we need to clearly
define what we allow with element access, especially in the case of
structured and sparse matrices. I would say that evaluating a matrix
element should be possible for any row and column index. However,
altering the content of an element might only be allowed for specific
positions in the matrix (for those familiar with ublas: recall the
discussion on symmetric matrices, row and column proxies, etc). For
example, if a symmetric matrix is defined by its upper triangular part,
do we allow changing a lower triangular part element? Do we allow for
changing a sparse matrix element that is structurally not there, i.e. do
we allow to change the sparse structure by element access?

The evaluation of expressions should be possible in various ways. For
example using BLAS calls, using unblocked and blocked expression
template mechanisms, using some user defined routines, etc. There should
be a way to distinguish between all these cases. Do we allow the user to
create his own routines and plug them in the expression template mechanism?
We should also allow the user to expand the expression mechanism. For
example, suppose a user wants to add the function element_sin( m ) that
computes an expression that contains the sines of the elements of the
matrix without creating a temporary matrix.

Which value types do we support? int, float, double, complex<T>. Do we
support any user defined value_type, for example rational numbers,
polynomials, that the user may have? If yes, we should define the
minimum interface for a value_type. In addition, we may want to have a
traits class (cfr value_traits in ublas) to implement special functions,
such as conj(), abs(), invert(), define functions that return zero and one.

That is it so far.

Have a nice end of 2004 and good start of 2005

Karl