Re: [eigen] General design issue

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

2009/11/13 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>
>
> On Fri, Nov 13, 2009 at 8:58 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> Hi,
>>
>> Wow, your mail took me a lot of effort to understand, I think it's
>> mostly ok now...
>>
>
> sorry for that, I should have been more explicit.
>
>>
>> First of all, I agree with your summary of current limitations. Yes, I
>> agree we must take care of that before beta1.
>>
>> Let me rephrase some stuff in my own baby words to see if i got it
>> right. The 2 basic problems you want to address are:
>> * code sharing between dense and sparse xpr
>> * in xpr trees, only the leaves should be affected by what the leaves
>> actually are.
>>
>> The "naive" approach to that would probably be to let e.g. Transpose
>> and SparseTranspose inherit a common base AnyTranspose, making it a
>> curious base so AnyTranspose<Derived>... then .transpose() methods
>> should return objects of AnyTranspose<Derived> which is ugly and may
>> (out of empirical experience) give compiler warnings about strict
>> aliasing when casting the returned object to the derived type.
>>
>> So your solution, if I understand well, consists instead in letting
>> Transpose itself be a template in one more integer parameter, which
>> you call StorageType, which could have special values Dense, Sparse,
>> Band...
>>
>> At this point, I think I have understood how you solve the "the rest
>> of the tree doesn't completely change if the leaves are different"
>> problem.
>>
>> But can you enlighten me as to how you solve the "code sharing"
>> problem? If Transpose<Dense> and Transpose<Sparse> can share code,
>> where do you put that? In a common base class TransposeBase? So that
>> problem and solution is actually completely orthogonal to the above?
>
> What I suggest is a bit different. Let's pick an example:
>
> template<MatrixType> Transpose : public TransposeImpl<MatrixType,
> ei_traits<MatrixType>::StorageType>
> {
>  int rows();
>  int cols();
>  MatrixType::Nested m_matrix;
>  // etc.
> }
>
> then TranposeImpl<MatrixType,Dense> would inherit MatrixBase<Transpose<> >
> and implements the coeff() methods while TransposeImpl<MatrixType,Sparse>
> would inherit SparseMatrixBase<> and implement the InnerIterators mechanism.

ok so actually in your scheme, the code sharing happens in the derived
class Transpose, while the non-shared implementation happens in the
base class TransposeImpl.... clever!

What I like the most here is that the class that is used as a node in
the xpr tree, Transpose, doesn't get any additional template
parameter: our xpr trees were already complex enough like that...

Are you going to set up a new fork for that? And add it to the
todo-3.0 page? It seems quite a long project to complete.

Benoit