Re: [eigen] Rotations and unit vectors

2013/5/7 Hauke Heibel <hauke.heibel@xxxxxxxxx>

Hi Benoit,

On Tue, May 7, 2013 at 4:47 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> 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).

Could you explain why you think this is an issue? What kind of crashes are you referring to? When I hit an assert in a debug session, I get the exact line in my source code in which the error occurred.

The problem is that asserts are found in more than developers' debug sessions:

1. some applications ship builds with asserts enabled to users;

2. some projects have automated tests with strict policies on regressions, making very high the cost of intermittent failures.

You could however object that returning NaN's can make tests fail just like a crash does. So maybe my point #2 is largely moot.

There remains 1. No matter how loose the threshold is, I am afraid that you will run into it, even in code that doesn't look obviously buggy, because imprecision can accumulate arbitrarily much. For example, you could have code representing the view rotation as a 3x3 matrix, accumulating rotations by multiplying that matrix by another rotation at each frame, eventually getting a matrix whose determinant departs farther and farther away from 1.0 (exponentially, as it would get multiplied by a statistically constant factor at each frame). They you would take your camera rotation matrix's first column to build a rotation, and boom, it wouldn't be a unit vector at all.

So in short, any assertion on FP values will crash applications for end users.

Benoit

If I were seeing something like

assert( abs(axis.squaredNorm() - 1) > eps); // just an example

maybe even with a comment, there is hardly a more simple method to point me directly to the issue. Maybe that's different on other systems.

I already like the idea of a loose threshold (e.g. sqrt(numeric_limits<double>::epsilon())) as suggested by Gael. Any code which triggers such a threshold e.g. due to numerical issues definitely has a problem and by quietly accepting these values we only delay the issue from surfacing.

Regards,
Hauke