Re: [eigen] Re: proposal: call the Geometry module experimental

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

yes I agree the current Scaling is somewhat limited. What about the
following proposal:

1 - rename Translation TranslationProxy and slit Scaling in
UniformScaling, AxisAlignedScaling and GenericScaling.

2 - Add the global functions Translation and Scaling which would
auto-magically instanciate the correct proxy type. Then you can
directly use Translation and Scaling without bothering about the
scalar type and dimensions (unless you want to declare a proxy object
or reuse). Here is an example:

Scaling(2)

would return:

class UniformScaling<int> {

template<typename OtherScalar, int Dim>
Transform<OtherScalar,Dim> operator * (const Transform<OtherScalar,Dim>& t) {
  Transform<OtherScalar,Dim> res(t);
  res.linear() *= m_factor;
  return res;
}

// plus all other supported products

Scalar m_factor;
};

or something like that. It's just an idea.

Gael.

On Fri, Jan 23, 2009 at 1:37 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2009/1/22 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> the current situation have at least 4 advantages:
>> - it is consistent with AngleAxis, Rotation2D, Quaternion, etc.
>> - it allows nicer ctor: Translation(1,2,3) versus Vector3f(1, 2,
>> 3).asTranslation()
>> - it allows ctor from scalar: Scaling3f(2);
>> - it allows for storage if someone want (think about the current
>> issues with DiagonalMatrix)
>>
>> (ok ok the 2nd and 3th could count for 1)
>>
>> and they are already very simple classes. The proxy you propose would
>> not be simpler, just replace the storage Matrix by a reference and add
>> the respective MatrixBase functions and you're done.
>>
>> This is my current opinion, but as you know I changed my mind several
>> times by the past, so if you have good arguments who knows !
>
> OK, good points. In Eigen I tend to have this idea that we should
> avoid introducing new types when possible, but here indeed it makes
> sense.
>
> I think my only remaining real concern is about the naming.
>
> For rotations we have EulerAngles, AngleAxis, Quaternion, but not Rotation.
> Likewise for scaling we should have a specific, explicit name for this
> kind of scaling, not Scaling.
>
> How about:
> - ScalingFactors
> - StandardScaling
> - StdScaling
> - ScalingAlongAxes
>
> Notice that a general scaling is just a selfadjoint matrix, it's the
> same thing! So a general scaling is a very very general notion.
>
> Cheers,
> Benoit
>
>
>