CGAL users discussion list

[Marc Glisse <>]

On Wed, 15 Dec 2010, Rosen Diankov wrote:

> Dear CGAL developers,
>
> We've been considering using parts of the CGAL math backend for a
> robot motion planning environment named OpenRAVE (
> http://openrave.programmingvision.com ) in order get much more
> reliable computation results. The documentation and presentations have
> really hammered in the point that CGAL cares about precision.
>
> However, looking at the include headers, it seems that the standard
> C++ implementations of atan, asin, sin, cos, etc are used. Does this
> mean that CGAL considers their errors insignificant?

Basically, the answer is that CGAL doesn't use sin, cos, etc. At least not 
where it matters. If you try to call sin on one of the CGAL types (say 
CGAL::Gmpq) it will give an error.

A strong idea in CGAL is that you can do computations exactly (usually you 
don't because fast low-precision computations are enough to guarantee the 
result, but you can detect the cases were extra precision is required), 
which is possible for algebraic operations but not so simple for sin/cos. 
Besides, the usual geometric algorithms don't need trigonometric 
functions.

How much do you need trigonometric functions in your application, and what 
for? CGAL wants exactness when it evaluates predicates, and sometimes when 
it constructs objects in a clear geometric way (so if you construct the 
point of intersection p of line l with some object and then test whether 
p is on l you get a consistent answer). For the rest, approximations may 
be fine.

> In search for better standard library functions, we stumbled onto crlibm
>
> http://lipforge.ens-lyon.fr/www/crlibm/
>
> I'm sure the developers have heard of this library, so why isn't it a
> part of CGAL? Is it not as accurate as it claims?

Oh, I am sure it is very accurate (note that some standard libraries may 
be just as accurate). But that is not the same meaning as we use in CGAL, 
where we want exactness (more precisely, we don't care about the precision 
as long as we can guarantee that the sign is correct, which may require 
more precision that you can get from double). mpfr, which allows an 
arbitrary precision, is already closer to it, and is actually used in 
CGAL, in very specific ways.

--
Marc Glisse