| 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: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>
- Date: Thu, 29 Jul 2010 15:34:40 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=WX1/eTLqPPw7lOg4BSaNUeQv/32INEB3fUpZfU5Aayw=; b=Zpy2e5xozHjTQsZ1KWZR4g+DpB7yB2A0IYgZruinzHMew+2HOAjkWk7b6TXjaraycB A5/UbZHSaBgOloSYQB1dgPDxaROO424SrCjjCbKafOg7LLV6wm6UtomznIO1RzMcfLMc Jfk+0EZ/X4WAFJHxpWPAgYmYMhNRe1ayQN1mM=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Y+xKFP8h1Ie1+EuZLY/ZmqXkDOsJLS9RJXl1eSkxB57lWS8iY4ypYQ6hN/ILHPOoKB LBQo4UsRF7JW0PmSRB69viDs6HSsu0r0kk2Q4p30KBvZNZ3nbiF2XcUQHy8H3KIN/80x OWhDKAXgxEoJhe9WzMV/xzRalEK2qhfCNvEvQ=
On Thu, Jul 29, 2010 at 3:23 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2010/7/29 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
>> I forgot to comment on this before...
>>
>> On Thu, Jul 29, 2010 at 2:45 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>>>> Ok, the question is actually whether we want Translation, Quaternion,
>>>>> etc. behave like Transformations?
>>>
>>> Translation and Quaternion are different beasts here.
>>>
>>> The reason for Transform to exist is to represent non-linear (i.e.
>>> affine/projective) transformations.
>>
>> Isn't it only the projective part that makes the whole thing
>> non-linear? It that were true, you have like 2/3rd of the cases being
>> linear ones.
>
> Linear (in this context) means f(ax+by) = af(x)+bf(y). (Equivalently
> it means "a matrix transformation without using any homogeneous
> coords".) That entails in particular f(0)=0. So translations are
> nonlinear, so isometries and general affine transforms are nonlinear ,
> unless of course their translation component is 0.
Ah. I see.
>> I was primarily thinking about adding methods
>>
>> ::matrix() (returns a homogenous matrix)
>> ::linear() (returns a pure matrix)
>> ::translation (same as ::matrix(), read only expression)
>
> What do you mean when you say that ::translation() is the same as ::matrix() ?
Sorry, I meant identical to what I proposed for Translation::matrix().
> I agree about having these method in all geometry classes for
> consistency although I wonder about their usefulness in the cases
> where they would be trivial (i.e. linear() in Translation).
It is just about being able to interchange types without being
required to rewrite the code. We can also go for the minimal set of
methods that makes sense, i.e. (both adapted to the Transform names)
RotationBase::matrix()
Translation::translation()
There is even one more thing. An easy one. We should add more static
asserts in Transform. In particular to scale and shearing functions.
They must not be used on Isometries.
- Hauke