|Re: [eigen] Rigid Transformations in eigen: discussion thread|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Rigid Transformations in eigen: discussion thread
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 18 Sep 2009 11:08:39 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=L+RaXMENnc5dw1dlkcJRFEtLh49ipDn/g36HdN9CzDc=; b=I9Cf0tgcs0H1i7Hs7LFczpzRzWcvUBX4lthe6sB0mWGbYos3R743vaa1Wr54Celv0u UNW+qAKQdpEBQMraD33B6HxttxU0GpT5U2d6adswVIHaSz5gd59yew79EN9e248coCs7 HzjbgS1fQylQ5i9VAGzLvhPgovjsVNzB70OWg=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=efx5A3c9n3ENDiSf7IuTSrmxirTSuGLmAc1bo++SOfXGhT7atHGYBD+V0QuPgOSZuR Uqa0UtxTi5u2zzseQjmMYxnLN+RkZci2nAbdHwfu7k20wtrcWWoMf6AdlLv+OWG0Zm5T 8TKm46loaSyOZsxY5ckS4qg9aX8pmlOsGiX54=
On Fri, Sep 18, 2009 at 7:41 AM, Rohit Garg <rpg.314@xxxxxxxxx> wrote:
>> Yes. So if the user is OK to cope with having to call coeffs(), then
>> he can do all what he likes, and get optimized code thanks to ET.
> But for just an interpolation, you should not have to write coeffs()
> everywhere. :(
> Is there no other way to get ET without coeffs()?
> How about the + and the * operator return vec8 expressions, and we
> provide only 1 assignment operator to take vec8 expression as input?
Another quite simple solution is to add a second template argument
being the type of the coeffs. By default it would be a Vector8_. For
instance operator* would be implemented as:
CoeffsTypeOfThis> > operator*(Scalar s)
return s * m_coeffs;
same for operator+:
CoeffsTypeOfThis, OtherCoeffsType> >
operator+(const DualQuaternion<Scalar, OtherCoeffsType>& other)
return m_coeffs + other.m_coeffs;
Then you add a ctor and operator= like this:
template<typename OtherCoeffsType> operator=(const
DualQuaternion<Scalar, OtherCoeffsType>& other)
m_coeffs = other.m_coeffs;
and you're almost done: you still have to take care to evaluate the
coeffs if needed in the compositing operator* and similar functions.
>>> The classic Grahm schmidt has a very poor numerical stability. It can
>>> be modified to run in a stable manner, but there is ~2x operation
>> Not when the matrix was already very close to being orthogonal, as is
>> the case here if you re-normalize frequently enough. In that case,
>> Gram-Schmidt is fine. But that is OT, as indeed it's never as good a
>> solution as quaternions.
>>> Another good point. What do you think of the current unit tests?
>> sorry, haven't had time to look at it carefully.
>> i guess the cout's aren't there to stay, for the rest i need to read
>> it carefully, have to run now...
> Rohit Garg
> Senior Undergraduate
> Department of Physics
> Indian Institute of Technology