Re: [eigen] Transform products

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Ok, all good. Here is a clean patch - in case you want to double check.

All geo_* tests are passing. I am just missing the 'make check' result.

In theory, I am also taking any expression on the RHS, as I said

A * (S * pts_3X)

is working and here the RHS is a product expression and now also

(A * S) * pts_3X

is working again.

One question. In Transform, the speciaization for the RHS product. Do
you prefer to use an

EIGEN_STATIC_ASSERT(OtherRows==Dim || OtherRows==HDim, ...)

or an

typename ei_enable_if<OtherRows==Dim || OtherRows==HDim,void>::type* = 0

- Hauke

On Thu, Aug 19, 2010 at 2:47 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2010/8/19 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
>>
>> Hi,
>>
>> first of al let me say l I agree with the changes proposed in the other
>> thread.
>>
>> However, DiagonalMatrix is used to represent non uniform scaling. For
>> instance Scaling(1,2) returns a 2x2 DiagonalMatrix. So this time I
>> think that
>>
>> T * DiagonalMatrix
>>
>> should really be interpreted as T * scaling, whence the following rules:
>>
>> Affine = Isometry * diagonal
>> Affine = Affine * diagonal
>> Projective = Projective * diagonal
>>
>> Who want to represent points using a diagonal matrix....
>>
>> Otherwise we would have to add an explicit NonUniformScaling class,
>> but this is exactly what a DiagonalMatrix is....
>
> Also, the old (current) code in Transform is taking any EigenBase, i.e.
> either a dense matrix or another kind of special matrix, in particular a
> DiagonalMatrix.
>
> That was nice when products were interpreted in the old way (interpreting
> the EigenBase as a Transform) but frankly not necessary, especially not with
> the new interpretation.
>
> So I think that you can just change that produce code to only take
> MatrixBase objects. So we drop support for special matrix classes. In the
> new interpretation of Transform products that we're coming to, it's not
> useful anyway. Then you don't have any conflict anymore with DiagonalMatrix,
> so you can add a separate operator* taking (Transform, DiagonalMatrix).
>
> Benoit
>
>>
>> gael
>>
>> On Thu, Aug 19, 2010 at 1:00 PM, Hauke Heibel
>> <hauke.heibel@xxxxxxxxxxxxxx> wrote:
>> > Ok, I am starting a new thread. The other one was way too long.
>> >
>> > I started with the RHS product refactoring. Everything went well,
>> > until I hit the case, where the RHS is a DiagonalMatrix. The patch is
>> > attached but I will anyways past the most important piece of code over
>> > here because it is hard to find in the diff.
>> >
>> > The function causing troubles is ei_transform_right_product_impl::run
>> > for Affine and Isometry. I tried to make a one fits all implementation
>> > and in theory, it works well. Even the inlining on MSVC seems to be
>> > working for fixed size types. For DiagonalMatrix, I am hitting the
>> > issue, that there is now way to extract a block.
>> >
>> > Here is how I tried to implement run:
>> >
>> >  EIGEN_STRONG_INLINE static ResultType run(const
>> > Transform<Scalar,Dim,Mode>& T, const Other& other)
>> >  {
>> >    EIGEN_STATIC_ASSERT(OtherRows==Dim || OtherRows==HDim,
>> > YOU_MIXED_MATRICES_OF_DIFFERENT_SIZES);
>> >
>> >    typedef Block<ResultType, Dim, OtherCols> TopLeftLhs;
>> >    typedef Block<Other, Dim, OtherCols>      TopLeftRhs;
>> >
>> >    ResultType res(other.rows(),other.cols());
>> >
>> >    TopLeftLhs(res, 0, 0, Dim, other.cols()) =
>> >      ( T.linear() * TopLeftRhs(other, 0, 0, Dim, other.cols())
>> > ).colwise() +
>> >        T.translation();
>> >
>> >    // This is a hack to circumvent the fact that DiagonalMatrix does
>> > not expose ::row(int)
>> >    // In fact, the code below will not even be used in release mode,
>> > but it will still be compiled.
>> >    if (OtherRows==HDim)
>> >      Block<ResultType, 1, OtherCols>(res,0,0,1,other.cols()) =
>> >      Block<Other, 1, OtherCols>(other.derived(),0,0,1,other.cols());
>> >
>> >    return res;
>> >  }
>> >
>> > I used Block in the end, because row() does not exist for
>> > DiagonalMatrix. Any Ideas? I would be too sad, if I were required to
>> > write a specialization just because of this since in general, the if
>> > clause is already removed by the compiler -- though it is still
>> > compiled.
>> >
>> > On the other hand side, who want to do something like this because now
>> > everything on the RHS is interpreted as points. If the RHS is 3x3 it
>> > is not any more interpreted as [S 0; 0 1]. The correct move would be
>> >
>> > A.linear() *= S;
>> >
>> > and even this works
>> >
>> > A * (S * pts_33)
>> >
>> > though this does not
>> >
>> > (A * S) * pts_33
>> >
>> > I could even go back to row() instead of block().
>> >
>> > I am pausing the patching for now, until I get feedback.
>> >
>> > - Hauke
>> >
>>
>>
>
>

Attachment: geo_prod.patch
Description: Binary data



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/