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

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

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

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

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

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

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Error: trying to recover Q matrix in sparse QR factorization** - Next by Date:
**Re: [eigen] Error: trying to recover Q matrix in sparse QR factorization** - 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/ |