|Re: [eigen] Rotations and unit vectors|
[ Thread 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: Tue, 7 May 2013 15:23:17 +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=yi0MYwX5KgtjD0/lVOpnvfbbDIicNiVny5U6ydGUjDM=; b=IceORT7iXzjG2UuKkuyBUxywWovtOwGEBSNcSNJvnAZqt+f007cYf7cDWt4HPmxwZk MkFc6W3hHh1kOkeI3vdqQOOxlgxHMpuAxl5Wql/ROMsMFwwNnU/e4w3LCzPRM2SgFAxr ugjHtC6sMPY3H7YhJlCkRB/jCvoUdhjmiZCsqWiUUVLXNjdywdK1T7s0TrLsWZC1kmVW u9UK8xNhsC2+zVhkaoIOPRYH3ihqIxK4SAR+UiK5MQYo7HxM1iw7Krp23icEywSJpfEE HVczi6GDNMf2xDv1MuaJQmBt7Gc5HbI889MtRTClHsxIXunm494fHQDnRs5YJEraYOhW CLRQ==
On Tue, May 7, 2013 at 2:04 PM, Christoph Hertzberg
> 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
>> 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,
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
>> 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
> Another possibility would be to check for unity every time the object is
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
>> 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
> Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
> Cartesium 0.049
> Universität Bremen
> Enrique-Schmidt-Straße 5
> 28359 Bremen
> Tel: +49 (421) 218-64252