| Re: [eigen] Do we need geometry refactoring? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Do we need geometry refactoring?
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Fri, 6 Aug 2010 10:16:40 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=v+cF2aRc/pd4cZlcR0y4DN8yYImC46uIOkwN/fJmg+I=; b=fd7c2JCjm5jM/zZiHLHZm9dBcOGIvm87JuFdTqnmpASlTq8uY5uCOFasb0ocDMlKWl u/lit9S+aL+K2sRJyIj/CEXWBok15riF8+OZhdBIkosMvGDPBIZn19++CQmBPwA0+hdP 9O0jHpZCirxF1yTg+ZmJS34GKzuI8LD8z+iQ0=
- 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=HEWon8y7tcppdq+HWQCuymr/mgTHyqheJVbcV9QKQuuGGcemrTPoMfMcaQwQhJP/4V NUqsafbBQRpx4oRHRjYljPNbO7cepAKbSw33Gw2sJ8TiLyH7IhAgJ9mS61f5dvwYyEar X+s2/q18ksAG7MRGCWI0wMrHNm3OeQDWBxQZI=
I like your plan, but this is a big change with API impacts so unless
someone steps up to do it now, it may be too late.
Meanwhile, just removing the Transformxx typedefs will already remove
most of the confusion. People using the Transform template directly
are already people with a better-than-average understanding of things.
Benoit
2010/8/6 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> 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:
>
> TransformationBase
> <- RotationBase
> <- Quaternion
> <- Rotation2D
> <- etc.
> <- Translation
> <- UniformScaling
> <- MatrixTransformBase
> <- Projective
> <- Affine
> <- CompactAffine
>
> Just a rough idea to further improve the current design...
>
> gael.
>
>
> On Wed, Aug 4, 2010 at 11:41 AM, Gael Guennebaud
> <gael.guennebaud@xxxxxxxxx> wrote:
>> 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
>>>> "generic".
>>>
>>> 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 ;)
>>
>> gael
>>
>>>
>>> - Hauke
>>>
>>
>
>
>