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

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

2009/1/24 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

OK, indeed if we agree that Aligned in this context sounds OK in English.

> 2 - add UniformScaling

OK

> 3 - add a global function Scaling working for:
>     float, double, std::complex<*>, 2 scalars, 3 scalars,
> MatrixBase<*> (square matrix or vector)

As I explain below I don't think it should allow square matrices.

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

OK

> 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 ?

OK, good idea. So there remains only UniformScaling (since I disagree
below for Scaling(square_matrix))

Then we could rename UniformScaling to just Scaling and there in the
doc we explain how to get the other kinds of scaling using explicit
matrix expressions.

> About UniformScaling, even though it is just a scalar, is still useful
> because Translation * scalar would be too ambiguous.

Good point.

> 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)

I think that can be completely removed. The idea is that if the user
is good enough in math to prepare the scaling square_matrix to pass to
such as Scaling(square_matrix) function, then he also is good enough
to understand that he can directly multiply his transform by that
matrix.

I find it more confusing than anything else, to have Scaling()
behaving as a wrapper around marked(). And that doesn't help the
matrix product to go faster.

Now I would like to restate my initial request: can we please mark the
Geometry module experimental? It doesn't have much disadvantage: we
just make sure to actually preserve the 99.9% of the API, and 100% for
Krita and other projects you might care about; but this allows us to
improve the API without artificial constraints. Then for 2.1 we remove
the experimental tag. I really don't think we should be having this
discussion a couple of days before eternal API freeze.

Cheers,

Benoit