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 [hidden email] 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 [hidden email] http://lists.boost.org/mailman/listinfo.cgi/glas |
Free forum by Nabble | Edit this page |