Re: [boost] Preview 2 of a template Geometry Library

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-03-27 16:35:39

Michael Fawcett wrote: 
> The actual minimal concept required is simply that every element of
> the sequences is able to be indexed into, is able to be multipled, and
> that their result is able to be added.  In this case, a boost::tuple
> would fulfill the model, so would a straight array with an appropriate
> get<> defined, so would boost::array...and with minimal work, so would
> any legacy point class.
> 
> So I think I agree that there isn't really a "PointConcept", but as
> shown here, there are still concepts that the algorithms require.  I
> suspect a lot of the algorithms dealing with points merely require
> that each element be indexable and also satisfy boost::is_arithmetic.
> 

[John Femiani] 
1.  I don't think a generic point concept can avoid compile time
indexing because you would have to support existing point types which
are structs or even encapsulated classes. I don't know a portable,
correct, and efficient way to do that.  If my algorithm _could_ be
implemented using CompileTimeIndexed instead of RunTimeIndexed then my
algorithm _should_ be written to the CompileTimeIndexed concept in order
to be more generic.  

2.  I think that one issue about 'points' is that they are often
represented by coordinates. Coordinates are the things that should be
indexable, and have arithmetic ops.  Points, IMO, should be described in
terms of the geometric transformations (rotate, scale, transform) that
can be applied to them.  It might not hurt to even factor those out into
TranslatableConcept, RotatableConcept, etc.  I also think that points
should have some metafunctions that serve the role of a Kernel, so that
you can figure out which distance metric is used by default, what its
result type is, and what the vector type is, or what the inner product
result should be.  Maybe that would be flexible way to handle the
robustness issues discussed in this thread.

-- John Femiani