|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: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>
- Date: Tue, 3 Aug 2010 12:26:20 +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 :content-transfer-encoding; bh=yJuGqCSpkhrMGjj5BtEfNOjoLun2LuvKXCUyqom1+vo=; b=ksP5Dlc2Bdyv9bpLvjSTmxTLem2AE49x4HKRD/fALAoAOade4J6VAxmLrAkRiJSKIC F3aUi/EIBMoJWSp9KWDdf8RgYb5d4XP0BsNIIINyygPztd4lmZ8ojmTG8Vg0Y5hB24qy uBJT5CNRXCVPiJ7gFTVG/aulKNsp0Socmdzhg=
- 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:content-transfer-encoding; b=W0QNmO4CFCbydnfgJdv5Zy3LbPpbHC5liAS85qs9g47oF3H0x9WxCBvUO1aSnO2i4P 54plpCv7HQ9FywzkTo9K7q90rme05yr9Wvv4tZtNuozsTgyd5feEhCi/lLCaykNHa5Dk 2+pY4+FYR1SbdxAtXvLkt8r6dxH6Uwl3WB2l0=
On Tue, Aug 3, 2010 at 12:05 PM, Manuel Yguel <manuel.yguel@xxxxxxxxx> wrote:
>> - Some users are happy because their old code keeps working
> Sorry, if I let pass that kind of frustration in my last mail :)
No sweat. You did not cause any frustration.
> The more general is generally the better for a default parameter
> however calling Transform3x a general 4d transformation is weird.
Why? I think I start to understand your confusion. Do you consider a
"Transform" to be affine and or isometric?
In our case the class for a general non-linear transformations is
called Transform and thus (IMHO), Transform3f should be as general
since the name is so close to the class name - it just implies
Dimensions = 3 and Scalar = float but the name does not give you any
hint that this should be affine. So the only thing I can safely assume
is that it is a general homogeneous transformation, as the docs state.
> If I understand correctly Hauke point, the graal would be to detect
> the following programming mistake:
> a composition of transformations with a non affine result used
> (thought as) an affine transform.
> I do not see how to do that really, but I agree with the goal.
This works now out of the box because unless you don't specify
(Affine3f = Transform<float,3,Affine>) it is assumed to be fully
projective. Your compilation will even break in case you use fixed
> Perhaps an alternative would be that Transform3x is Affine but not the
> default parameter of the class Transform ?
As I said. I don't like it because Transform3x implies a general
homogeneous 3D transformation but I accept your posting as a vote
against my proposal.
So 1:1. :)