Glas List: Re: [glas] Concept C++ [was Re: back to business}

From: Peter Gottschling (pgottsch_at_[hidden])
Date: 2006-11-29 08:58:31

On 28.11.2006, at 03:05, Karl Meerbergen wrote:

> On Mon, 2006-11-27 at 13:01 -0500, Peter Gottschling wrote:
>>
>> On Nov 22, 2006, at 9:14 AM, Karl Meerbergen wrote:
>>
>>> I see an immediate application of concept_map: glas::dense_vector
>>> becomes a EuclideanVectorspace, e.g.
>>>
>>>
>>> template <typename T>
>>> concept_map EuclideanVectorspace< dense_vector<T> > {
>>>   real_type norm() const {
>>>     return norm_2(v) ;
>>>   }
>>>
>>>
>>
>>
>> That is an interesting idea to define a concept-dependent default
>> norm. However, we have to consider potential conflicts for vector
>> types that model multiple concepts with different default norms.
>>
>>
>> template <typename T>
>> concept_map L1VectorSpace< dense_vector<T> > {
>>   real_type norm() const {
>>     return norm_1(v) ;
>>   }
>> }
>>
>>
>> concept L12VectorSpace<typename Vector>
>>   : L1VectorSpace<Vector>, EuclideanVectorSpace<Vector>
>> {}
>>
>>
>> One solution to resolve this conflict is to introduce a convention
>> which norm is prioritized over the other (assuming we can agree on
>> one).
>
> I think this kind of issues is application dependent. Do you know a
> situation where an algorithm mixes vector spaces for the same vector?

The problem is that the conflict not only arises when the different 
spaces are used in the same algorithm.  Concept maps are global and 
using the same vector type in different spaces (in terms of concepts) 
in the same compile unit (might be the whole application or large part 
of it) is already critical. Especially if we put several VectorSpace 
model declarations into libraries.

> Adaptors can be a solution that map a vector in a specific space.
>
This can help and indeed I could manipulate the model declarations by 
just deriving a new type (public) from another and give it different 
concept maps.  Nevertheless, we should be careful to not end up 
introducing a new type for every concept (or every combinations of 
concepts.  One way to do this is to leave concept maps out of libraries 
(or provide compiler flags to disable them).

May be such conflicts are not a serious problem in practice and I'm 
only overcautious.  We will see if we run into something, I just wanted 
to point out a detail we eventually have to think about.

It is also that I have a slightly different view on a 
EuclideanVectorSpace.  For me, it is a vector space that has a norm_2 
but I wouldn't say that this is necessarily the norm to use. Or 
probably this are even two different concepts: the existence of norm_2 
and considering norm_2 as THE norm. Of course, the second is a 
refinement of the first.

Best,
Peter
>
> Karl
>
>
> _______________________________________________
> glas mailing list
> glas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/glas
>
------------
Peter Gottschling, Ph.D.
Research Associate
Open Systems Laboratory
Indiana University
135 Lindley Hall
Bloomington, IN 47405
Tel.: [phone]   Fax: [phone]
http://www.osl.iu.edu/~pgottsch