Re: [eigen] Rotations and unit vectors |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Rotations and unit vectors*From*: Dick Lyon <dicklyon@xxxxxxxxxx>*Date*: Tue, 7 May 2013 09:45:34 -0700*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=yeqgU6IPhXWgvm/UBp9uJoXBXy7CNcXSJv6amYW8C2M=; b=FC/K7Sqw9W+3ukxloICx8B4wqpgim1kpsW8p+xidkmEbWfNfj8O0Gv8SFtSGxHyq8n VTkpg1HaXHSTK2Gy/PiCfcXpMxSg0YVz2zbA9U/gr3yj/Uvx4P4YFrz6PUCsZmqxvbLI V8Gdo4oX76V/HhUHYxCmbWSzq6gCjn3xz9CufFQkZwr9MW5Afz0WCPQHetIIRWYw/gCI OzAnXdXmFOsI/Blr9lqqMPe7CiyCaCJjbsv2nhbB0P7z4Py7DxTeoEW8NYP3MCK8OWIM jbhd9tw39z6PY7IfbzQP/jxtRlnRLrz/aIJKFksuEzngZ+LFadY+pVHBaKZe5QOn2TQO z1vw==

How about this: compute the norm of the unit vector, and compare it to 1. If it's not very close, don't fail out, but normalize the vector.

Or wrap existing functions with new versions that check and correct norms of unit vectors, so the programmer can use one or the other; or have a mode flag that controls whether to normalize; you could even have a mode to fail out, but people who want a strong check.

Maybe a CHECK_UNIT_VECTOR_NORM(vec, tolerance) that would compile to nothing, or to an assert, or to a re-normalization, depending on mode.

Dick

On Tue, May 7, 2013 at 8:51 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxxx> wrote:

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:*Christoph Hertzberg

**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

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Rotations and unit vectors** - Next by Date:
**Re: [eigen] Error: trying to recover Q matrix in sparse QR factorization** - 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/ |