Re: [boost] [GTL] redesign checked into sandbox

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2008-05-10 20:52:40

> John wrote:
> >So in my imagination, CoordinatesConcept and its refinements are what
> we
> >are
> >talking about. There should be related concepts of PointConcept, 
> >VectorConcept, LineConcept, OrientationConcept,  RayConcept, 
> >IntervalConcept, SegmentConcept and the _real_ killers are probably 
> >GeometryConcept and/or CoordinateSystemConcept....
> 
> Hmmm, interesting.  I've been thinking about a 
> coordinate_traits class similar to the follow to inform the 
> library of various types.
> 
> template <typename T>
> struct coordinate_traits {};
> 
> template <>
> struct coordinate_traits {
> 	typedef int coordinate_type;
> 	typedef unsigned int manhattan_distance_type;
> 	typedef double euclidean_distance_type;
> 	typedef unsigned long long area_type;
> 	...
> };
> 
> or alternately metafunctions for the same
> 
> template <typename T>
> struct area_type {}; //will not compile unless specialized
> 
> template <>
> struct area_type<int> { typedef unsigned long long type; }
> 
> template <>
> struct area_type<double> { typedef unsigned double type; }
> 
> Since I need to infer them somehow from the basic coordinate type.
> 

As you know I prefer the metafunctrions :)

> That is working under the assumption that all coordinates 
> have the same type, whereas your proposal looks like you want 
> coordinates to be convertable to a scalar type, but allow 
> each Dim to define a different raw_type.  What exactly is the 
> value of having different raw types?
> 
> What I'm doing with my library is basically saying the scalar 
> type is the coordinate type, and you can use whatever data 
> type you want to store the values in your object, but it 
> should convert to and from scalar type to be processed by the 
> library.  Is that unreasonable?
> 
> Thanks,
> Luke

I want the flexibility to allow 'at' to return a reference. The
references would then be to the underlying types internal members, which
could be of any type.

I have applications in mind where coordinates may be references to
unsigned chars, so the type of the reference can not be the same type
used for, say, an inner product.  

I required only a 'scalar' type because I figure that is the minimal
need. Coordinate elements, regardless of there raw types, need to be
mixed, added, divided, etc. 

Presumably things like euclidean norms are callable objects and
something like result_of<euclidean_norm(Coord)>::type can be used to get
or control its result.

In my concept a coordinate_accessor is a UnaryFunction object an I
should make sure ::boost::result_of works, huh..?

Also maybe there needs to be Metric or Norm concepts to, eh?

-- John