Re: [boost] Preview 2 of a template Geometry Library

From: Arash Partow (arash_at_[hidden])
Date: 2008-03-27 02:16:42

Joel de Guzman wrote:
 > This has been well discussed many times: make Point a concept and
 > allow many models of the Point concept. It is a mistake to have
 > a single do-it-all point class. What if I want a 2 dimensional
 > point with a short for x and a long for y?

This is the statement a software engineer makes not someone tasked
with solving computational geometry problems.

At some point the library (underlying concepts) has to place strategic
limits on what is and is not a viable representation for a geometric
entity - why stop at a point why not call everything a simplex and
parametrize things accordingly?

The Original poster's submission (not sure if it is a review) falls
dismally short of what a generic templates computational library
should be at the bare minimum let alone something useful by the
general populace. Far from simple nD objects, the spaces in which those
objects exists must be defined or defaulted, the kinds of operations
their bounds and limits must have definable taps within the library -
the "I'll template everything off-of traits and force the end user to
figure all the details out" view will not work here, as most people
intending on using the library will want to actually use it not
develop {for}it.

In your example:

 >>     cout << distance(p1, p2) << endl;
 >>     cout << distance(p2, p3) << endl;

(not assuming the previous defs),
In what space is this distance metric being computed (euclidean?
hilbertspace?)..?

what kind of precision are you after? should distance(p1, p2) ==
distance(p2, p1),

what about performance? I' want to write a gaming or graphics engine,
how can I get around the checks and balances that say a round such as
is_point_in_triangle will endure?

Will I have to reinvent the wheel every time I can't get the exact
thing I want out of the library?

None of these kinds of concepts are being described or addressed and
these are only a few of the simpler requirements. Writing a geometry
library is hard, look at CGAL over $1million Euros in funding, both
commercial and academic wings and look at the monstrosity they have
produced. If you can determine the intersection point of 2 line
segments in under 15lines of code using CGAL I take my hat off to
you :>

I would love it if there was a formal discussion on this ML about what
would constitute a computational geometry library that is worth of the
BOOST mark - not just random people coming up with their latest
attempt at one.

You really have to have done some work in this area before you can
even begin to consider the technical issues that are involved. A passing
experience usually gives the wrong impression about the complexity of
the problem(s) in this field.

Arash Partow
__________________________________________________
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all things.
http://www.partow.net