Re: [eigen] Rotations and unit vectors

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Tue, May 7, 2013 at 2:04 PM, Christoph Hertzberg
<chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> On 07.05.2013 13:12, Hauke Heibel wrote:
>>
>> I understand these issues but personally, I am more concerned about the
>> performance in release mode and prefer to have errors risen when I am
>> using
>> a library in the wrong way in debug mode.
>
>
> Maybe we could introduce a new flag like EIGEN_TOLERANCE_CHECKING or
> EIGEN_INPUT_CHECKING (similar to EIGEN_INTERNAL_DEBUGGING)? Then we could
> also check if user-given rotation matrices are actually rotation matrices,
> etc.

We already have to many of such flags for that a library that claims
to be easy to use!

>> The issue about mutating functions is tricky. We have it in quite a few
>> places in the Geometry module, e.g. Transform::linear()/matrix(). These
>> mutating functions pretty much break the encapsulation of the classes.
>> Fixing these (as opposed to removing them) is a little bit more
>> complicated
>> since the only solution I see is the introduction of proxy objects which
>> would do the checking which already sounds messy. :)
>
>
> This still leaves a tiny loophole if someone const_casts the .axis() const,
> or somehow else gets direct access to the data of the axis. But I guess we
> must accept that C++ will always leave possibilities to shoot oneself in the
> foot.
>
> Another possibility would be to check for unity every time the object is
> used

that's what I suggested.

> -- that would not
> raise the assertion when the error happens but arbitrarily later.

not super nice, indeed.

>>> 3 - Which tolerance? Shall we strictly enforce that
>>> axis.normalized()==axis? shall we tolerate some epsilon??
>>>
>>
>> Maybe epsilon could be computed as the upper bound of the error which
>> could
>> be imposed by calling axis.normalized() but I am not sure - probably this
>> error is depending on the magnitude of the original axis. Furthermore, I
>
>
> I'm pretty sure that it does not depend on the order of magnitude.
> I don't see any way how a.normalized() and (2*a).normalized()) can lead to
> different results in IEEE754 math (unless one over-/underflows).
> However, I guess it's not too trivial to determine how big that error can
> get exactly (But extensive random testing and multiplying the maximum error
> by maybe 2.0 or 4.0 should be sufficient).
> Furthermore, there might be users who accept certain errors and normalize
> their vectors using the fast SSE rsqrt, giving them a relative precision of
> about 11bits, so hard-coding an epsilon is quite likely a bad idea.

Actually the following is not always true:

a.normalized().squaredNorm() == a.normalized().normalized().squaredNorm()

Another typical use case is when taking the cross product of two
orthogonal unit vectors...

Perhaps a reasonable solution would be to ignore mutating accessors
and use a relatively high tolerance to only detect clearly
pathological cases. That would probably be enough to detect 90% of the
bad uses.

gael

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