Re: [eigen] random thoughts -- we need more Gaels |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] random thoughts -- we need more Gaels
- From: Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>
- Date: Sun, 3 Oct 2010 20:36:50 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=+2+8Paq6R1RiUMT4JO/AnNGCReY6wbRhS408YOvxQis=; b=OhHevddY4NNSWcX1wGhkbTQXczzktZAsiN0m3ui8h73t3+7bZQYjhOwFPeOq6lxhE1 Dno8L9GbbYjTyxn1jON7IFvxELwqUWV1Ff5hw4PT0NIBimf3wBOyjZBd8YPij/m9H98T WzwkXBqzlQSib+1aSPW4G2SfCvEwwKLG/4JEs=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Ui6V5rRFDLvy0W9TkucVeuxPR64WeASR37DuaK/JWqPWO4cJyzkeCGAri68QFVMOzR dd7AgfRHBnN4ojRE8LUpKCWWM1pU0ox+Ikc5Ehy38835nkeCu7F+2fVB3KAVi/3JpneT m3hRrlxG+LScyPLGOF/kAk3Pr/slAZzWxvt74=
I don't want to comment much on this because we agree that we need
more documentation or at least better organized documentation. But it
is wrong to say there is nothing and here are a few links:
http://eigen.tuxfamily.org/index.php?title=Developer's_Corner
http://eigen.tuxfamily.org/index.php?title=Eigen3_Developer_Documentation
http://download.tuxfamily.org/eigen/meetings/paris2010/Gael-NewInternals.pdf
I think we are quite heavily mailing list oriented and some (actually
many) questions have been answered here multiple times where a Wiki
page or some docs would have been better - saving us from repeating it
all over...
On Sun, Oct 3, 2010 at 7:04 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> Eigen wasn't any more commented when Gael joined --- it was just much
> smaller (1000 LOC), so it was possible for him to grasp the overall
> design without documentation.
It is similar for me and I dropped in much later and therefore I would
like to mention one thing which I personally find quite complicated
and which was introduced at the Paris meeting. Just as an example ...
The problem originates in wanting maximal flexibility and having
minimal overhead for the introduction of new classes and algorithms.
The example is the class DenseStorageBase and there are others like
that. A part of the (already deprecated) class hierarchy can be found
in the last document I linked to above. It appears as if
DenseStorageBase were inheriting from multiple base classes though
this is not the case but it is rather the case that its base class is
depending on the derived class. This is an odd pattern and one of the
things which increased the entry level difficulty.
Personally, I spent many hours investigating the code and in the
beginning it was at least easy to deduce the base classes but even
that is now tricky but doable once you know what to look at.
I think some good starting points where we need more docs are:
- the base classes (even in code) and how they are chosen
- classes such as CWiseBinaryOp et al. because they are the foundation
of many simple, low-level math algorithms
Regards,
Hauke