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*: Mon, 13 May 2013 09:16:37 -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=2AKuXQsQUBF7uUZirD7TC13yepqRtfdG7LY1OTGzqNY=; b=JnPHrTBcVYUF/nvQV6fp/e19zxjAF2iWeN0gssFiCWKepvulIXmAuGlmaV/EENyKAm ZR5wRSyYoklWeaqkDMRZA46VGNLln216zkFIV9GyOoRHbnKK9H/t5apG6bLjd335JzMw DEgYcvOflLjc2BRXulHv4J7fXEqJa+l7xEIelDG2PnTm9E1FYBmW3WZxrFaoicydhkUl FpSxmxJNdgDMVTEzMD9/UYcHvvMgTkuGXHxlAZv2nU5GYx8qoFvldQkL3hClp9RLkKIt p2dLvHpeCEc9ZLpR/kjtLwrDhT+vYAzsKkJt1iLw6vF1xe6PRduTdcjKnQ+WzQQAYuxc e6wg==

2013/5/13 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>

On Mon, May 13, 2013 at 7:55 AM, Hauke Heibel <hauke.heibel@xxxxxxxxx> wrote:I'm also in favor of option a).

> Just to summarize. I think in general, we agree that we should try to cover

> at least the most basic cases in which the user can create invalid objects.

> So far we have two reasonable options

>

> a) use asserts enabled ifndef DNDEBUG

> b) use NaNs to signal a wrong usage

>

> Personally I am still for option a), despite Benoit's reasoning. The main

> question remaining for both versions is how to choose a good threshold..

OK, go ahead, I was just giving some input.

Benoit

Both fail with fast normalization routines.

> Here, we also have two options on the table

>

> a) Eigen's dummy precision (I think something like 10e-15 for double and

> 1-e-5 for float)

> b) sqrt( numeric_limits<Scalar>::epsilon )

>

> a) probably provides better support for user defined scalars and b) is less

> strict than a) and is more unlikely to raise asserts when they are not

> necessary

sqrt(NumTraits<Scalar>::dummy_precision()) works with my tests.

gael

> Regards,

> Hauke

>

>

> On Wed, May 8, 2013 at 1:42 PM, Christoph Hertzberg

> <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

>>

>> On 07.05.2013 18:45, Dick Lyon wrote:

>>>

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

>>

>>

>> I guess, normalizing every time would be more consistent then. I assume an

>> inverse sqrt is more expensive than a comparison and a branch, but as both

>> need to be done quite often, it could even be cheaper on average.

>>

>>

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

>>

>>

>> That would again be another flag which changes global behavior.

>> And, especially if you switch from auto-normalization to do-nothing, you

>> can get very subtle bugs (both versions work, but the latter gets more and

>> more inaccurate over time).

>>

>> I would vote for just asserting accuracy (which will be disabled in NDEBUG

>> mode), possibly with a customizable tolerance. Most importantly, a program

>> which runs fine in debug mode should give the same results in release mode.

>> And a program that fails in debug mode shall be allowed to give undefined

>> results in release mode.

>>

>> As for asserting or throwing:

>> It is possible to change eigen_assert to throw instead of assert and so

>> far eigen_assert is the only way Eigen indicates non-recoverable errors

>> (though mostly these are dimension mismatches etc)

>>

>>

>> Christoph

>>

>>

>>

>>

>>

>> --

>> ----------------------------------------------

>> Dipl.-Inf., Dipl.-Math. Christoph Hertzberg

>> Cartesium 0.049

>> Universität Bremen

>> Enrique-Schmidt-Straße 5

>> 28359 Bremen

>>

>> Tel: +49 (421) 218-64252

>> ----------------------------------------------

>>

>>

>

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

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

**Re: [eigen] Rotations and unit vectors***From:*Christoph Hertzberg

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

**Re: [eigen] Rotations and unit vectors***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Eigen SPQR support memory leak** - Next by Date:
**[eigen] Zero-Sized Blocks** - 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/ |