Re: [eigen] Permuted Matrix

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

this is more or less done, waiting for the tests to compile, will
commit tomorrow...

gael

On Tue, Jul 20, 2010 at 5:00 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2010/7/20 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> Hi,
>>
>> it appears this would be welcome for Reverse, SwapWrapper and
>> SelfCwiseBinaryOp... The later ones are internal only, so it was fine
>> to have DirectAccessBit for them. For Reverse, well it could sometime
>> have DirectAccessBit with a negative inner stride, but not always.
>>
>> Do you confirm this requires a new WritableBit flag?
>
> I didn't remember about that, but that's indeed very ugly (and I'd
> rather not do negative strides!)
>
> So yes, that's more reasons to add a new WritableBit, or LvalueBit, flag.
>
> Good that this is all internal --- it's very welcome to fix now but
> IMO it doesn't have to block 3.0.
>
> Benoit
>
>>
>> gael
>>
>> On Tue, Jul 20, 2010 at 12:30 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> Hi,
>>>
>>> You're not missing anything, actually you understood everything very
>>> well. You really hit a limitation in our design here. Expressions are
>>> either DirectAccess, which assumes a simple memory layout, or have no
>>> write support at all. There's no middle ground. These two cases
>>> correspond to the two cases in DenseCoeffsBase, as you found out.
>>>
>>> The fix is to add a third case in DenseCoeffsBase, in between the two
>>> existing cases in the inheritance diagram. The three cases could be
>>> called respectively, "direct access", "lvalue without direct access",
>>> "rvalue-only". Or something like that.
>>>
>>> Fortunately for us, this is something completely internal so we can
>>> fix it later --- so please understand if I don't have much motivation
>>> to do it right now :) Feel free to send a patch though.
>>>
>>> Cheers,
>>> Benoit
>>>
>>>
>>> 2010/7/19 ESCANDE Adrien 222264 <adrien.escande@xxxxxx>:
>>>>
>>>> Hello,
>>>>
>>>> I'd like to implement a permuted matrix i.e. a matrix P base on another M, such as P(i,j) = M(r[i], c[j]) for some permutation vectors r and c. It is very similar to the subject of another thread (how to create a "virtual" array or matrix) whose conclusion was to look at the way Minor class is implemented.
>>>>
>>>> Based on this Minor example, it is indeed easy to implement a PermutedMatrix class for read-only purpose. It goes like this:
>>>> template<typename MatrixType> class PermutedMatrix
>>>>  : public MatrixBase<PermutedMatrix<MatrixType> >
>>>> {
>>>>  ctor
>>>>  overload of coeff and coeffRef
>>>> }
>>>>
>>>> One can then access to coefficients of the matrix, use block expression, triangular view,...
>>>>
>>>> Writing in such a matrix is however a problem: PermutedMatrix can't have the DirectAccessBit bit because the "layout of the array of coefficients" is not "exactly the natural one suggested by rows(), cols(), outerStride(), innerStride(), and the RowMajorBit" DirectAccessBit documentation).
>>>> Thus PermutedMatrix  only derives from DenseCoeffsBase<Derived, false> and not DenseCoeffsBase<Derived, true>. In particular, it does not inherit the good operator() (Index, Index), and the copyCoeffByOuterInner(Index, Index, const DenseBase<OtherDerived>&) methods, the latter being needed in the assignation.
>>>>
>>>> Adding these missing methods directly in PermutedMatrix solves part of the problem: one can do P(i,j) = some_value or P = some_matrix, but they are still missing in expression based on PermutedMatrix , thus one can not do P.block(i,j,r,c) = another_matrix, because the copyCoeffByOuterInner of DenseCoeffsBase<Expr<PermutedMatrix<MatrixType> > > (in my example, Expr is Block) is not correctly defined.
>>>>
>>>> Do I miss something on this problem ? Any direction I could take, or flag I don't know of ? I'm not very familiar with Eigen internals yet, so any pointers would be welcome.
>>>>
>>>> Thank you,
>>>>
>>>> Adrien Escande
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>