CGAL users discussion list

[Marc Glisse <>]

On Thu, 16 Dec 2010, Rosen Diankov wrote:

> I really like your idea of maintaining the estimate of the angle as
> arctan! So I would just return an Object that stores two values: (y,x)
> internally, and will automatically call atan2(y,x) whenever the user
> requests it to be converted to a decimal.
>
> However, this means we would also have to accept these objects in the
> "set joint values" function for the robot. Most users do something
> like:
>
> values = GetJointValues()
> values[i] += offset
> SetJointValues(values)
>
> So if we want to maintain exactness,

The question that only you can answer is: do you need exactness with 
respect to these user actions, or only internal exactness within your 
library for consistency reasons? Also, you could document the version that 
acts on angles as inexact and add to the interface a version that takes a 
cos (or sin or tan) and is better suited for exactness.

> then the 'joint angle' object
> would have to store the history of the math operations so that the
> internal SetJointValues can process it exactly?
>
> What helper objects does CGAL provide to do this?

The whole Lazy_* framework works by remembering in each object the 
sequence of operations that led to it, plus an approximation. When the 
approximation proves insufficient, we recompute the whole sequence (or 
only part of it then update the approximation?) exactly and then forget 
the history. The issue with your functions is that sin cannot be computed 
exactly. However, it shouldn't be too hard to adapt the code so that 
instead of collapsing the history while performing an exact computation, 
it simply reperforms the computation with more precision (using Gmpfi 
possibly, although the wrapper functions to mpfi_sin is currently 
missing). The algebraic kernel might already have something like this 
(Gmpfi was introduced for a reason after all ;-). The hardest part will be 
the math part of determining when to stop.

--
Marc Glisse