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

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2007-10-03 21:35:23

>>> Suto, Gyuszi wrote:
>>>> The biggest issue is agreeing on fixed vs. floating precision.
>>>>
>>> If it's going to be a template library why not both?
>> 
>> The floating point has high resolution near zero and very low
resolution
>> at high values. 
>
Joel de Guzman wrote:
>Ok, but then again, there are also problems with fixed point.
>So, again, why does the library have to choose and not the
>user, since we have templates?

You are asking me what my rationale was for not templating the
coordinate data type.  That is a good and useful question to ask.  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.  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.  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.  The built in equivalence operator is effectively meaningless in
floating point and a lot of the code would become nonsensical.  There is
a big difference between fixed point geometry and its application
domains and floating point geometry and its application domains.  I am
skeptical that a generic geometry library could successfully bridge that
gap by templating the coordinate data type.  Someone working in a
floating point application domain should feel welcome to contribute the
floating point library.

Lucanus Simonson