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