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

From: Arash Partow (arash_at_[hidden])
Date: 2008-03-28 10:13:52

 > I also agree with you here, but would like to propose the EGC (Yap and Co.)
 > related stuff be done within the object's value type not the algorithm. But
 > then you'll say: well I can get better than normal precision from certain
 > perdicates and PODs  using Shewchuk's methods. To that I would say lets define
 > a series of operators and predicates and then develop algorithms based on those:
 >
 > ie: distance that was:
 >
 > return std::sqrt((x1,x2) * (x1,x2) + (y1,y2) * (y1,y2));
 >
 > now becomes:
 >
 > return sqrt(add(sqr(sub(x1,x2)),sqr(sub(y1,y2))));
 >
 > where the routine making the call will have a computation_trait that
 > will define add,sub,mul,div etc for that type and a policy oriented
 > approach would easily allow the user to pick and choose between EGC
 > and "fast and loose" computational precision/speed models.

Would like to retract this part, due to the fact that if robustness is
properly taken into account then a holistic solution which not only
concerns itself at the operations level (add,sub etc..) but also at
the routine level is required, as the greatest errors come from the
combination of the results from each of the operators not the
operators themselves.

At the end of the day one may end up with a CGAL style naming convention
where the specifics of the routine are spelt out in its name - not a good
idea though.

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