Re: [boost] [GTL] - geometric template library - determining interest

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-10-04 05:44:36

Simonson, Lucanus J wrote:
> In looking at the recent submissions to boost related to geometry there
> is a fair amount of overlap with our library, particularly in what I
> call the basic types such as point2d.  The ideal outcome from my point
> of view is that we all benefit from a synthesis of ideas and craft a
> boost geometry library together that goes beyond the code we will
> initially submit and will continue to be enhanced and extended with the
> participation of the community over time.  

Yes, absolutely.  We need to decide what the foundations should be, and 
the Point type is one of the most basic.  Could you post your point2d class?

Some of the choices are:

* Coordinate type: it's pretty clear to me that that should be a 
template parameter, for which you can supply an integer, fixed-point or 
floating-point type.  Some algorithms will depend on particular types 
being used, e.g. my space-filling-curves code doesn't work with 
floating point, but that doesn't mean we have to prohibit such kinds of 
points entirely.

* Homogeneous vs. heterogeneous coordinate types: for example, in a 
mapping application, latitude and longitude are (almost) the same type, 
whereas altitude has an entirely different range and might benefit from 
using a different type e.g. a different fixed-point scale factor.  So 
do we have one template parameter or n template parameters?

* Fixed or variable number of coordinates: I'm happy with 2d and 
sometimes 3d points and using distinct types for them, but some people 
think in higher dimensions and need points with arbitrary numbers of dimensions.

* xyz or [n] notation: using .x, .y and .z to access the coordinates 
seems simpler to me, but the higher-dimension people would prefer to 
use [0], [1] ... [n].  That notation also has the advantage that you 
can iterate through the dimensions.  Is it possible to support both?

* Accessors or simple variables: should I write p.x or p.x() or 
p.get_x() ?

* Member functions or free functions: p.distance_to(q) or 
distance_between(p,q) ?

I'm sure there are more.

Phil.