Re: [eigen] Rotations and unit vectors |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*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 <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 likeassert( abs(axis.squaredNorm() - 1) > eps); // just an examplemaybe 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

**Follow-Ups**:**Re: [eigen] Rotations and unit vectors***From:*Dick Lyon

**References**:**[eigen] Rotations and unit vectors***From:*Hauke Heibel

**Re: [eigen] Rotations and unit vectors***From:*Robert Lupton the Good

**Re: [eigen] Rotations and unit vectors***From:*Benoit Jacob

**Re: [eigen] Rotations and unit vectors***From:*Hauke Heibel

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Rotations and unit vectors** - Next by Date:
**Re: [eigen] Rotations and unit vectors** - Previous by thread:
**Re: [eigen] Rotations and unit vectors** - Next by thread:
**Re: [eigen] Rotations and unit vectors**

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