status

[Karl Meerbergen]

  Hello all,


It is a long time that (Toon and) I posted some news about the on-going
work. Currently, there is documentation, code and test code for basic
vector containers (dense_vector, mapped_vector and sparse_vector) in GLAS.

We have chosen to start the development of prototype algorithms:
norm_2 : prototype of algorithms with a single vectorexpression argument
that return a scalar result
dotu (and dotc) : prototype of algorithms with 2 vectorexpression
arguments, returning a scalar result
collection *= scalar : prototype of function on a collection and scalar,
with a void result
vectorexpression * scalar : prototype of function with vector and scalar
argument returning an expression result type
collection += vectorexpression (prototype of function of a collection
and a vectorexpression)

Implementations for GLAS (using indexed loops on collections, i.e. using
v[i]), BLAS and VSIPL backends.

At this stage, there are no views such as ranges or slices. Also, the
assignment policies we talked about earlier are not developed (or
documented) yet.

Toon will shortly upload all changes on the website.

The file glas/doc/concepts/overview.dia gives a clean overview of the
concepts.

for checking out, please use subversion:
svn checkout https://svn.sourceforge.net/svnroot/glas

I think, we are on the right track. Before continuing the development of
other algorithms we want to make sure that doc and code are consistent
and complete for the algorithms and containers that are there.

Note that the core does not contain operators such as +=, *, etc. Some
of those are defined in the toolbox LA, which is still far from
complete. Recall that there was no agreement on the list on the meaning
of operations. This is application dependent and operators are therefore
defined in toolboxes as are other functions (recall the inner_product
discussion).

We have tried to make the organisation of the documentation consistent
between concepts and core models and algorithms. The concepts are used
for dispatching the algorithms; e.g. the meta function
is_sparse_vector_expression<V> checks whether V is a
SparseVectorExpression. Each VectorExpression and VectorCollection has a
concept type that is a boost::mpl::vector containing the concepts it is
model of. I still regularly find errors in the doc or inconsistencies
between doc and code, so this also needs to be fixed and tidied up
before adding new containers, views and algorithms.


Karl


_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas

[Karl Meerbergen]

Hi,

I spoke to our colleague Greg yesterday who is developing finite element
software and he wanted some permutations of a vector (related to some
ordering of eigenvalues). It is something we did not yet think of. He was
refering to where this done in matlab. (Matlab is a great source of
inspiration for glas for both functionality as syntax).

Concerning permutations, I see three possibilities:
* We can add a permutation algorithm and a related view, without permuting the
vector explicitly, which has some advantages when the value_type is quite
large in size.
* Add a function to permute a vector explicitly
* Add both.


For those who are familiar with the current svn tree ...

Toon and I have introduced cursors (can be an index or a pointer or an
iterator) to walk over an expression and funtions to increment the cursor:
  vector.next(cursor)
  vector.next(cursor,step)
and evaluate
  vector.value(cursor)
  vecor.index(cursor) (for the sparse case only)

Currently cursors can only walk in a forward way over the vector. (cfr
ForwardIterator)

With such a permutation, this is a case where prev(cursor) and
prev(cursor,step) should be added to the SparseVectorExpression and
DenseVectorExpression concepts.

Algorithms carried out on a permutated vector, using next(cursor) and
next(cursor,step) need the prev() functions to implement the next() of such a
permuted vector (without explicitly carrying out the permutation), although I
am unsure it is enough. We might need a random access change of the cursor
also for efficiency reasons. This should become clear once we implement
permuations on vector expressions.

Karl
_______________________________________________
glas mailing list
glas@...
http://lists.boost.org/mailman/listinfo.cgi/glas