|Re: [eigen] Do we need geometry refactoring?|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Do we need geometry refactoring?
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 6 Aug 2010 09:35:15 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=FD7Ua+bDq3eezckQxbZtS0D5IihAYBLiMl8QhoA2qMo=; b=GN9FnnDBxsmnSGKESn3R4cZwfmJ/Eo9QubkGxCP5+deEJu9mZeVI+s4rV1KKUEuNCi ETlPIM7v40aa/CJ4AkGX3eDLbEWOQXx4ML2PPJ3gxpeoKy62Drlw7wCquM8goHyF0YJe UNXTI/OeOxD51hPwgJRytjSFPn+y1h56khICw=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=hG+mQMGI6tEqJWLsUEpVYbByc9JuCecbH11ZXeB+ovaASnCK2mE1ocY2ztOEK4mu2z X1oBEJ08R3iYiURoFRPpvegGpox1DhmZ4FaeOu51bzkVNmzM+osJkLaxvUFcXCept5BC uEHl+CDTRNkKyi7M3l/nLRejaaD1lpnSjbeu8=
hm, maybe the name Transform is not precise enough and confusing. So
what about introducing three types: ProjectiveTransform, Affine, and
CompactAffine. They would internally inherit a common base class to
factorize what can be factorized. And to better unify all
transformation classes (Projective, Translation, Quaternion, etc.)
what about having a common base class for them exposing a common API
(including the translation, linear, etc. parts). The inheritance
diagram would look like the following:
Just a rough idea to further improve the current design...
On Wed, Aug 4, 2010 at 11:41 AM, Gael Guennebaud
> On Tue, Aug 3, 2010 at 4:42 PM, Hauke Heibel
> <hauke.heibel@xxxxxxxxxxxxxx> wrote:
>> On Tue, Aug 3, 2010 at 3:53 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>>> - It is unintuitive that the most generic Transformation is affine
>>> Let's focus on this point because it looks crucial to me. The most
>>> generic transformation is definitely projective, there's no question
>>> about that, the questions discussed here are:
>>> a) what should the default value for Mode be?
>>> b) what should the Transform3f (etc) typedefs stand for?
>>> Obviously, a typedef named "Transform3f" has to use the default mode,
>>> but at the same time that name "Transform3f" does suggest something
>>> generic, whence the confusion in this discussion between "default" and
>> Right, you nailed it. So, we agree that Transform3f is likely to
>> suggest something generic.
>>> What do you think about this plan:
>>> - we just remove the Transform3f... typedefs. We just force the user
>>> to use the mode-specific typedefs such as Affine3f, Projective3f, etc.
>>> - we don't give Mode any default value.
>>> - in the tutorials, we focus (at least at the start) on Affine
>>> transforms, Affine3f etc, so that the intuitive idea that 3D-transform
>>> * 3D-vector gives a 3D-vector. Of course we then do explain other
>>> kinds of transform.
>> Sound like a plan. Gael, do you have any opinion?
> while reading this thread this morning I was going to suggest the
> same, so yes I agree ;)
>> - Hauke