Skip to Content.
Sympa Menu

cgal-discuss - Re: [cgal-discuss] Robust math using crlibm

Subject: CGAL users discussion list

List archive

Re: [cgal-discuss] Robust math using crlibm


Chronological Thread 
  • From:
  • To:
  • Subject: Re: [cgal-discuss] Robust math using crlibm
  • Date: Wed, 15 Dec 2010 10:15:08 -0800 (PST)

minor correction, my test bursts werer 10,000,000 logs per burst (the receiving box had 128G of ram)

David Lang

On Wed, 15 Dec 2010, Marc Glisse wrote:

Date: Wed, 15 Dec 2010 19:04:22 +0100 (CET)
From: Marc Glisse
<>
Reply-To:

To:

Subject: Re: [cgal-discuss] Robust math using crlibm

On Thu, 16 Dec 2010, Rosen Diankov wrote:

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.

Do the angles really need to be explicit? The most convenient would be if angles were reprensented by their tan (or sin or cos) and the actual value of the angle in radians or degrees was only implicit (you could always output an approximation when asked).

In CGAL, most questions we have to answer on the input are predicates with a discrete answer (yes/no, +/-/0, etc). And I guess that most of your motion planning is just that, except for outputting an approximate route at the end.

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.

Note that one the main interests of the exactness is for internal consistency (if the tests tell you that a<b and b<c and c<a, your algorithm is likely to fail in various unpredictable ways, and this kind of inconsistency happens extremely easily). It might be quite ok to approximate the coordinates of the input once at the beginning (your first cos/sin, maybe keeping the constraint that cos^2+sin^2=1).





Archive powered by MHonArc 2.6.16.

Top of Page