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