Re: [eigen] Do we need geometry refactoring?

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/8/3 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> On Tue, Aug 3, 2010 at 2:33 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> Eeek, a lot of people will be expecting that Transform3f * Vector3f
>> gives a Vector3f, I didn't think about this.
>>
>> This is a really big argument in favor of the old default Affine for
>> Transform. What do you think about reverting to Affine?
>
> Absolutely nothing. :)
>
> When outvoted, I am ready to switch back but let's just look at the
> list of pros/cons.
>
> pros for switching back:
> - Some users are happy because their old code keeps working

Well, it's not just about old code: new users will keep coming,
expecting that Transform3f*Vector3f gives a Vector3f.

>
> cons against switching back:
> - 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".

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.

Benoit

> - Some users are unhappy because expectedly correct code like this
> produces wrong results (one of my strongest arguments)
>
> Transform3f T( some_projective_4x4_matrix );
> Vector3f v;
> T*v
>
> "Hmm, and I was sure I read that Transform3f's model non-linear
> transformations!??"
> - In 90% of the cases, we can be hope (I admit this is not a strong
> argument) that the users will get a compile time error for the example
> in question because the fixed size dims are not fitting (v' = T*v when
> T is projective)
> - Last chance to get things right since Eigen 3 will anyways break
> lots of Eigen 2 code or we are stuck with this forever
> - It is the right thing to do .... ;)
>
> Ok, I am passing the choice back to you and other people on the list.
> As I said, outvote me and I will revert this change.
>
> Regards,
> - Hauke
>
>
>