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

[ Thread Index | Date Index | More Archives ]

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

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.


Mail converted by MHonArc 2.6.19+