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: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Mon, 13 May 2013 11:23:31 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=0ufqzg5sA612io7Xnu6SsOtLFfiB0dvgw7+K3BRu8M8=; b=0SohIgVg63xt/sbD8a8PnPXy/uwO3CGKxyaBWbksIVqKuWaqlff/uLwe+mFDMFPn3a x7XnIIR2CzTheZcZ8P6bULzLT72Ydgv2lBeo7Kdqtn+e5bvCSIMFY+nnM+PuQTyFFoK6 7UhvbFxyCVX9mnY5OY0++2pRuydEMfqpQT5DKQEFiWcdwJRH8Ikj6s2utLRk6I9Rb+E6 MVVW6dp0LFPliKHS/XbiU0L913EsVLCXJvc4HRAo2kU9Sm2C5f5qezZVaqNF+CITvGq3 pXq0+IXmx+Ytc+UlfIZwd+eOAfc26EbrsCtyAn0PvHokFF6nzZCalOuNK0JDPQnvWxMC IUZg==
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).
> 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
>> ----------------------------------------------
>>
>>
>