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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

ok, I've already have some local changes which go to this direction.
Currently this is what I did:

1 - rename the current Scaling => AlignedScaling
2 - add UniformScaling
3 - add a global function Scaling working for:
     float, double, std::complex<*>, 2 scalars, 3 scalars,
MatrixBase<*> (square matrix or vector)

Since there is a single kind of translation, no need to rename it and
we can keep it as it is now.

However, I'm thinking that AlignedScaling could be removed, especially
once we'll have a better DiagonalMatrix as we discussed in another
thread. In practice Scaling(vector expression) would simply be an
alias for .asDiagonal(). What do you think ?
About UniformScaling, even though it is just a scalar, is still useful
because Translation * scalar would be too ambiguous.
Currently Scaling(square_matrix) simply returns square_matrix but I
think it could be an alias for marked<SelfAdjoint>(), right ? (only if
the SelfAdjointBit is not already there)

Gael.


On Fri, Jan 23, 2009 at 8:54 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> On Fri, Jan 23, 2009 at 8:07 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> 2009/1/23 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.
>>
>> I'm not favorable to GenericScaling. What is a GenericScaling? it's
>> just a self-adjoint matrix. The two notions are equivalent (hint:
>> diagonalize your selfadjoint matrix, now it looks like a scaling...)
>> If people want to multiply a transform by a GenericScaling they should
>> just multiply by that matrix.
>
> yes sure there is no need to have a GenericScaling stuff....
>
>>> 2 - Add the global functions Translation and Scaling which would
>>> auto-magically instanciate the correct proxy type.
>>
>> Aaaah this is the definitive solution. Decouple the actual class from
>> the name that the user sees.
>> Then if you add the Proxy suffix for translation for coherence we
>> should add it to the scaling types too?
>
> I added Proxy to Translation because I wanted to have Translation as a
> global function, but perhaps there would be a better name for that
> class. For "axis-aligned-scaling", if we agree that AlignedBox is
> explicit enough, then AlignedScaling should be ok too, but of course
> AxisAlignedBox and AxisAlignedScaling are more explicit.
>
>> Also:
>>
>> Can a Native English Speaker (tm) here tell us how good/bad
>> AxisAlignedScaling sounds? The same usage of the word Aligned can also
>> be found in our AlignedBox class. It is meant as "oriented along the
>> standard axes". Is that correct?
>>
>> Can we say that the very existence of this discussion is a good reason
>> to mark the whole Geometry module as experimental?
>> (Still doing our best to preserve compatibility for existing projects) ?
>
> as long as people don't use Translation and Scaling for storage then
> I'm pretty sure we'll keep API compatibility for them.
>
> gael.
>