Re: [eigen] Rotations and unit vectors

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

On Mon, May 13, 2013 at 7:55 AM, Hauke Heibel <hauke.heibel@xxxxxxxxx> wrote:
> 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..

I'm also in favor of option a).

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

Benoit

> 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

Both fail with fast normalization routines.
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
>> ----------------------------------------------
>>
>>
>