|Re: [eigen] Re: proposal: call the Geometry module experimental|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Re: proposal: call the Geometry module experimental
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Sat, 24 Jan 2009 19:32:59 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=uvKxiJqmb/OR4smvlyUqYz6SbiiI3hGFW5kJWhDqEPg=; b=jckX/Za1YA/fZ6JizJgQKbBRsN/N3bsRQ6u4HvBN0xkphcsd87OJMWHtrdVX51Zyj3 1DV8LdlSNTkpBIQQpQSYF36vEs87hSBLdcUPPtI0dL3SxJksRnF9wAY2xspnHrPmI1Ev +rKPkVKkhvU5A4P08H7AK7rAzx9hQqW0dg+UI=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Z5lXfOyZgUW3eaK9p77UzXNIFsvDOSb/0WvycD7bqltynvDA5mwPvjqGTw7lY+B/S6 O6QkibFi2K/CFcpQI1diu0ReWxvHbXFuS3q1KehrAkJhaSTDlBG8xGTRBJPkfrE1/9vC wzqkqOcPcmKkYXaoPaYbaY3xYH89EcrIPPHr4=
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)
On Fri, Jan 23, 2009 at 8:54 PM, Gael Guennebaud
> 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.
>> 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.