CGAL users discussion list

[Rosen Diankov <>]

Thank you for the quick replies!

I did a quick grep on the include folder and found uses of std::atan2,
that's why I was asking about it.

I understand your points about not using trigonometric functions as
much as possible. In fact, when dealing with pure geometry, it is
rarely necessary to deal with sin/cos/tan.

Because OpenRAVE is a motion planning package, it requires two things:

- converting a rotation around an axis to a quaternion (using sin and cos)
- solving the joint angle using atan2 (used in inverse kinematics)

Unfortunately, the configuration space of the robot (ie joint angles)
is an inescapable reality.

We're just getting into CGAL, so these questions were mostly for
figuring out what to expect when integrating CGAL into motion
planning. The idea of exactness and reliability is very attractive for
industrial-based applications.

rosen,

2010/12/15 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
>
> --
> You are currently subscribed to cgal-discuss.
> To unsubscribe or access the archives, go to
> https://lists-sop.inria.fr/wws/info/cgal-discuss
>
>