status

  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
glaslists.boost.org
http
://lists.boost.org/mailman/listinfo.cgi/glas

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
glaslists.boost.org
http
://lists.boost.org/mailman/listinfo.cgi/glas