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

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-10-04 12:02:27

On 10/4/07, Phil Endecott <spam_from_boost_dev_at_[hidden]> wrote:
>
> * 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?

I have code that supports heterogeneous coordinate types in 2D, 3D,
and 4D for exactly the example you gave - I do GIS related work.
There was a lot of trickery involved to determine appropriate return
types for things like:

vec3<float, float, short> result = vec3<short, short, short>(1, 2, 3)
+ vec3<float, float, short>(1.0, 2.0, 3.0);

I suspect there are now Boost libraries that will make that easy (or
at least easier).

> * 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.

Instead of coding a generic class that supported N dimensions, I made
a 2D, 3D, and 4D class.  Functions like cross_product and dot_product
only worked on certain types, but thinking about it, there's no
barrier to making that work with a generalized point class.  I did
however code a separate quaternion class as I felt it was
significantly different than a 4D point.  I have no strong opinion on
the implementation of this.

I do think that it should support Boost.Units though, so I can do
something like:

vec3<nautical_miles, nautical_miles, feet> radar_range;

> * 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?

It's possible to support both, either through Fusion, or through a
static array of pointers to members.  It's also possible to support
swizzle notation through functions with some macros that I made last
year, e.g. you can do:

float4 c = a.xxyy() + b.wwzz();

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

I much prefer p.x and/or p[0].

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

For functions that modify, I prefer member functions:

p.normalize();

but I also provide free function versions of all member functions that
copy/modify/return, like so:

float3 normalize(float3 pt) { return pt.normalize(); }

just so that it's easier in client code when that behavior is desired.
 For functions that do not modify, I prefer free functions:

distance_between(p, q);

Just my 2 cents...

--Michael Fawcett