Re: [eigen] Rotations and unit vectors

[ Thread Index | Date Index | More Archives ]

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.



Mail converted by MHonArc 2.6.19+