|Re: [eigen] General design issue|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] General design issue
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Fri, 13 Nov 2009 15:46:52 -0500
- 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=0DpDZ+xjDhCY1dXeWqgGFzFLJ87TuDihSBaX25hnzuU=; b=SRolNuNL0WEoGwKGhtarxFbergKbN0Ia82Ad9cjM1g6C8qXkEjE3jYCYl5/VCCpSx8 2Zy9/81a5Gpa9Yx+dzn1/O/+LJsH/aJVna4iaQFwA1YbC5DYwmGJClMHcVf/jLW79aOY P8WNYkifvnyXM520CfOqKB90rvPdf7nhFe2wE=
- 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=XAIPgh/yOxHlt2/7Dto/TcgjQ0Bct3S//4HOh13xTqGtySUeQmxSX6aqX7KJDraAdG Z/gHNpnh6wKfvkKqOTExw9A7whF3JpofjFpgIzxWzoiWuZUrgLAktV1ZNxme3NVA1f1J RP/Myvx063se2ANKawRncQytdx0Y0oGFkd730=
2009/11/13 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> On Fri, Nov 13, 2009 at 8:58 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
>> 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,
>> 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"
>> 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,
> 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.