Re: [boost] [GTL] - geometric template library - determininginterest

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2007-10-04 14:34:15

Simonson, Lucanus J wrote:

> It was a conscious decision I made based upon the benefit it would
> provide
> vs. the cost of adding an additional template parameter to each and
> every geometric class.

That you would need an *additional* template parameter would be a 
consequence of a particular use of temples.
You could follow the CGAL way: all geometric classes are parametrized in a 
*single* traits class.
The traits class itself provides all the types and operations needed.

> Just because "we have templates" doesn't mean
> that we don't incur a cost in using them.  The cost I was concerned
> with
> was ease of use, primarily.  Similarly I didn't template the
> dimensionality of geometry types because the benefit (primarily saves
> me typing) wasn't justified by the added complexity and difficulty
> using
> the library that choice would have caused.

But parametrizing the coordinate type and the dimension are two different 
things.

There is a finite mumber of practical dimensions, typically, (1..4) (Truly 
"D" dimensional geometry is a whole different game).

But the choice of coordinate type is not merely fixed-point vs 
foating-point.
There are interval number for filering, big-float numbers for sqrt-free 
none-rational arithmetic, lazy numbers for constructive reals, big integer 
rationals for exactly artihmetic, etc, etc, etc..

>  Instead I chose to pay the
> costs of templating to get much bigger benefits from ease of
> integration.  Incidentally, I do have a typedef for the coordinate
> data
> type, and you can easily change it to double, but the code wouldn't
> work.

But it would work if you changed it with CORE::Expr for instance, just to 
name an example.

>  The built in equivalence operator is effectively meaningless in
> floating point and a lot of the code would become nonsensical.

Or, the operator would throw in the presence of uncertainty in the floating 
point comparison if an interval type is used.
So a lot of code would work as fast as it can get so long it remains 
sensical, and give up as soon as it does not.
And you could try the code again with a slower but exact number type.
But none of this is possible if the arithmetic layer is not parametrized.

As I said in a different post, discussions about basic geometric elements 
such as points need a different perspective than discussions about 
domain-specific elements like axis-aligned rectangles where fixed-point is 
such a good choice that parametrization is mostly pointless.

-- 
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com