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