Re: [eigen] Rotations and unit vectors
• To: eigen <eigen@xxxxxxxxxxxxxxxxxxx>
• Subject: Re: [eigen] Rotations and unit vectors
• From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
• Date: Tue, 7 May 2013 11:51:40 -0400
• Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=5Hht3NuF2fbN5ufvXfihUSgdsQxLSCfFEthT0BA072w=; b=o/29c4veoZfDiZ+YSvDXNKpauZ0ZfwSXHH/+mR1HSoxEvH8eLygah5zFiZ8Sqm4FN7 Pl0etHJr8HQ1iliuN4LXDzcRIV75PfKpTAMNMI1pEujXkklvaIf/nOauo1bCv5SgHLgD g00j0P8ayx9CaYtAawb+wV6eb08TtQaaVbGJePs2ex4P2crT17p1JzPZqK2pT03xhE93 zEpxsotBL26s7gr/VDG7Wj67wKNh4bTJtmaZxLW1z95YOhwonS6Ej7b7j3p1pEN80sDU Lvi+ixhy2QL9d3enc6uORRY85af9LNjV8WtnjpBWZ8A4/JAZi5BKAPf2TcurauaWblf4 zMCg==

2013/5/7 Hauke Heibel
Hi Benoit,

On Tue, May 7, 2013 at 4:47 PM, 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).

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

 Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/