Re: [eigen] Rotations and unit vectors

[Andreas Keil <keil.andreas@xxxxxxxxx>]

Hi Benoit,

On 2013-05-07 16:47, Benoit Jacob wrote:
> [...]
> But it's probably never OK to assert on anything that can depend on 
> floating point values: that gives too finicky crashes (it doesn't help 
> much that it's only #ifndef NDEBUG).
> [...]
> You would still have to use a quite large tolerance to avoid this 
> kicking in when it's not wanted... do we still have the 'dummy' 
> precision values? That would be a decent choice.

I agree, in general. However, in the case of conversion of rotations 
from axis/angle or quaternion representations to other representations 
like a rotation matrix, reaching a program state where the norm is not 
very, very close to 1 is invalid because it does not represent a 
rotation. This invalidity is independent of how the vector was computed 
and whether it is only due to a numerical inaccuracy. IMHO, it does not 
matter which possible scenarios exist to get to a non-normalized vector 
that is meant to represent a rotation. The only question that matters 
for me is that it *is* representing a rotation closely enough.

I therefore vote for using a threshold like sqrt(eps) or even smaller in 
a debug assert. I would argue that this is the least Eigen should do to 
ensure that its AngleAxis and Quaternion classes represent what they are 
named after.

One could even demand from these two classes that they normalize any 
vector they are (re-)initialized with. But I understand the performance 
issues that may render this solution inappropriate.

> [...]
> Benoit
> [...]

Cheers,
Andreas.