Glas List: Re: [glas] MTL3 design ? [was MTL project site is up]

From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-02-03 03:35:34

Patrick Kowalzick wrote:

>
> From: "David Abrahams" <dave_at_[hidden]>
>
>> Guntram Berti <berti_at_[hidden]> writes:
>
>
> [snip]
>
>>> I think it will not be uncommon to wish to forbid even assignment
>>> between vectors of equal size, for example if one represents
>>> cell-based and the other one vertex-based quantities (speaking
>>> FEM). So one could introduce mechanisms to forbid assigment at
>>> compile time (i.e. making those vectors different types).
>>
>>
>> Or const?
>
>
> IMO for a "user" there is an easy way needed to create a bunch of 
> vectors with different _semantic_ meanings. One example is Guntrams 
> FEM example. Another one might be the representations of geometrical 
> entities, e.g the semantic difference between points and vectors. This 
> truly depends on the mathematical context.
>
> Having different types makes it much easier declaring functions for 
> some action. As an example take two vectors[3], where one represents a 
> point and the other a line in a 2D homogeneous space. The affine 
> transformations for both types must not be equal, so the functions 
> should be overloaded:
>    point affine_transformation( const matrix & a, const point & x );
>    line affine_transformation( const matrix & a, const line & x );
>
> Both points and lines _are_ vectors, but behave completly different. 
> E.g. addition of both is forbidden.
>
> In uBlas I inherit from the bounded_vector (but I am not completly 
> sure about side-effects).
>
> Regards,
> Patrick

Perhaps, we should introduce some notion of AssignmentAdaptor that takes 
a container and adds some constraints to the assignment? What do you think?

Looking at all reactions about assignment I do not believe we will agree 
on a single assignment policy, because some do not like assigning 
vectors of different sizes, others do. The GLAS user should be able to 
easily develop his own AssignmentAdaptor.

We then could have a very slim container but a bunch of adaptors that 
describe the behaviour of for example assignment, element access, etc.

Karl