Re: [eigen] random thoughts -- we need more Gaels

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


2010/10/3 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> 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

True... but we need 20x this amount of developer documentation.

>
> I think we are quite heavily mailing list oriented

(which, by the way, is about to change with the bug-tracker move)

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

That's true! We need to develop a habit of reply to such questions by
creating missing wiki pages.

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

I see what you mean, I agree we need to explain this coding pattern
(metaprogrammed inheritance relations)

Benoit

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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/