|
Boost : |
From: Kresimir Fresl (fresl_at_[hidden])
Date: 2002-05-08 16:25:51
Hi Joerg
> the main problem, which something
> like the clear()/insert()/erase() interface is intended to solve, is that
> the sparse vector assignment
>
> void operator () (V &v, const vector_expression<E> &e, sparse_tag) {
> check (v.size () == e ().size (), bad_size ());
> v.clear ();
> typename E::const_iterator ite (e ().begin ());
> typename E::const_iterator ite_end (e ().end ());
> while (ite != ite_end)
> v.insert (ite.index (), *ite), ++ ite;
> }
>
> has to work for dense, packed *and* sparse lhs (if only the rhs is sparse,
> the whole assignment is demoted to the sparse case).
Obviously, you are right. I forgot that clear()/insert()/erase() are used
inside other ublas functions/operators.
> As you stated correctly, a STL conforming clear()/insert()/erase() interface
> doesn't solve the problem, although it is related. So either we rename some
> of the functions or redefine the semantics at least in the dense case.
As the example with std::vector<>::resize() and std::valarray<>::resize()
in my previous post shows, even the semantics of standard functions is
not consistent. So redefinition is one option. Besides, the position
parameters of std::<Container>::insert() and std::<Container>::erase()
are iterators, while in the case of correspoonding ublas::vector<>
functions
they are indices. Different parameter types can signal different semantics.
But as with lower/upper_bound(), renaming is probably a clearer option.
English is not my mother language, but I fill little uneasy with `zeroise()'
instead of `clear()'.
Maybe `insert()' could be called `assign()' or `assign_at()'.
Semantics of ublas::vector<>::erase() is to assign zero to
some vector component, so the new name can be `assign_zero()'
or `assign_zero_at()'. Similarly, ublas::vector<>::clear() assigns
zero to all elements; as it takes no parameters, it can also be
called `assign_zero()' or, more verbose `assign_zero_to_all()'.
Sincerely,
fres
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk