Boost logo

Boost :

From: Michiel Salters (Michiel.Salters_at_[hidden])
Date: 2001-12-17 04:38:57


> -----Original Message-----
> From: Ralf W. Grosse-Kunstleve [mailto:rwgk_at_[hidden]]
> Sent: Thursday, December 13, 2001 11:48 PM
> To: boost_at_[hidden]
> Cc: rwgk_at_[hidden]; nksauter_at_[hidden]
> Subject: [boost] vector_algebra ideas
>
>
> Our work often requires operations on vectors of numeric data.
> Unfortunately the STL does not provide adequate support for all
> our needs. E.g. valarray (section 26.3.3.1 in the ISO standard)
> only defines homogeneous operators such as
>
> template<class T> valarray<T> operator*
> (const valarray<T>&, const valarray<T>&);

Note that this is not a member of valarray<T>.
 
> I am thinking about light-weight, general approaches for enabling
> element-wise algebraic vector-vector and vector-scalar operations
> (e.g. operator+(), operator*(), etc.) on generic sequence types
> (e.g. std::vector or boost::array).
>
> I see two possible approaches:
>
> 1. Inherit from the "raw" sequence type (e.g. std::vector) and
> define all the operators as members or friends.
>
> 2. Define general template operators in a "vector_algebra"
> namespace.

I fail to see the reason for inheritance here; I think containment is the
better
solution here for all the standard reasons (failling IS-A test etc). I also
fail
to see why you'd want the functionality as members, since you wouldn't
have any private data anyway ( certainly in case of inheritance ).

So I'd say all you need is the type logic to create
template <typename U, typename T>
valarray< { combination of T and U } >
operator* (const valarray<T>&, const valarray<U>&);
i.e. alternative 2
[ SNIP alt. 1]
> This code works with the compilers listed before. Here is the general
> idea: There is a "top-level" template operator such as:
>
> template <typename TypeLHS, typename TypeRHS>
> typename algebra_traits<TypeLHS, TypeRHS>::promotion_type
> operator+(const TypeLHS& lhs, const TypeRHS& rhs);
>
> To enable vector algebra for a given sequence type, algebra_traits
> is partially specialized (see top of vector_algebra.cpp):
>
> template <class T, class U>
> struct algebra_traits<std::vector<T>, std::vector<U> >
> {
[...]
> };
>
> Two similar specializations are required to enable vector-scalar
> and scalar-vector operations:
>
> struct algebra_traits<std::vector<T>, U>
> struct algebra_traits<T, std::vector<U> >
>
> To enable use of the algebra in a certain scope:
>
> using namespace vector_algebra;
>
> Note that this enables operators for heterogeneous types, e.g.:
>
> vector<int> + vector<double>
> vector<double> + int
> etc.
>
> Even the following is possible (see corresponding
> algebra_traits at the
> top of vector_algebra.cpp):
>
> vector<int> + boost::array<double, 3>
> boost::array<long, 3> + vector<double>
> etc.
>
> Note that the usual operators (such as int + double) are not affected
> since the unspecialized algebra_traits dispatches to std::plus etc.

Actually, they're not affected because non-templates are preferred over
template functions during overloading.

> There is one catch, though: operators defined by the sequence type as
> member or friend functions (maybe even in the namespace of
> the sequence
> type?) take precedence. E.g., in the case of std::vector, the std
> boolean operators (==, !=, >, <, >=, <=) take precedence over the
> operators brought in with "using vector_algebra;", but only for
> homogeneous expressions such as vector<T> == vector<T>.
> An expression such as vector<T> == vector<U> would use the
> vector algebra. This can easily lead to confusion. Therefore
> the prototype implementation does not define the boolean operators,
> but vector_equal_to etc.

That's one risk. Another risk is your operators colliding with other
templated operators. A solution might be to provide thin wrapper
classes among containers, with the only purpose of having the
containers in namespace algebra_traits. This would enable Koenig lookup.

Regards,

-- 
Michiel.Salters_at_[hidden]
CMG Trade Transport & Industry / 
RTSE1 - Technical Software Engineering

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk