Re: [eigen] Geometry module - Quaternion fitting alternative |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Geometry module - Quaternion fitting alternative*From*: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>*Date*: Tue, 26 May 2009 16:21:19 +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 :content-transfer-encoding; bh=8TAQccLuyzVsp4XFVUD7CQnJcMsAFyWTqc1OC6+yPIA=; b=jkGhUoyqZKjdEmIA1UtZLsr446/247VWrohAKlKltNqJPWDmokPR35OU1tbUsj3XkY xb++25QBdid+s0syi4Gf7EQbjKBDObB2+MxNRagpSeaa7IR8+wUrkBalOT/NFqHv0CVZ yc3EjEehSAapW91jGKdi0mSmS3DbhZA16PsY8=*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:content-transfer-encoding; b=Z8UMQuM1pmGFTFcymE3PCGf1hr8pPG316lGTZyu6UNH1q21YJ++ck2XI9jgZ/kuRUq a0hJLgcnKa7FSdHz5sk6jz8Maeq5C+l2ctkL5AtH1XIwmDzTyqLl2cRf09M7xymcM35g NwvrHY4LDU3sT6k6HJcu24dK67mpFlxPJF+xM=

wow that's a very great contribution ! I did not read the code but I still have a few comments. On Tue, May 26, 2009 at 3:31 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote: > 2009/5/26 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>: >> This means that a prerequisite to vectorize that is that your matrices >> src and dst be RowMajor. > > Oh but I overlooked the fact that dst and src are the arguments passed > to the function. So we don't control their storage order, the user > does, and the default is col-major. We could say that you change the > implementation so that now the _rows_ are the points, so vectorization > can be done in the col-major case... but that would mean interleaved > storage, so the construction of the matrices in the first place would > be less efficient (less memory locality) so it's probably not worth > it. then I would say use the highest level Eigen expression as you can, and hope that in some situation the vectorization will be enabled. For instance there are still a few possibilities to improve the vectorization of partial reduction. Also note that the geometry module already requires the Array module. Also it would be very cool to describe the underlying algorithm in 2/3 sentences so that the user know what to expect (complexity, etc.). If this is already the case just forgot what I said ! I'm wondering whether the Geometric module is the right place for that ? More generally I'm wondering whether we should favor few but fat modules, or many but light ones ? For instance, if we want to go for the few but fat solution, then we could also have a single Decomposition module with LU, LLT, QR, SVD,, etc. !! Personally, I prefer the "many but light" solution. This is why I'm suggesting to put this algorithm in a new module, just like a Levenberg-Marquat solver should have its own module. Again, this is just a suggestion... Gael. > So I'd say don't worry about vectorization here.... > > Benoit > > >

**Follow-Ups**:**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Benoit Jacob

**References**:**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Hauke Heibel

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Benoit Jacob

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Hauke Heibel

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Benoit Jacob

**Re: [eigen] Geometry module - Quaternion fitting alternative***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Geometry module - Quaternion fitting alternative** - Next by Date:
**Re: [eigen] Geometry module - Quaternion fitting alternative** - Previous by thread:
**Re: [eigen] Geometry module - Quaternion fitting alternative** - Next by thread:
**Re: [eigen] Geometry module - Quaternion fitting alternative**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |