Re: [eigen] Re: meeting in February?

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

2010/1/11 Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>:
> After some time passed by, I do have now some ideas of what we might discuss
> and work on. We might want to
>
> a) ... double check, that we are really getting the nesting straight
> b) ... try to find out whether and where the code base offers simplification
> c) ... discuss ei_traits vs. class typedefs and ei_traits unification
> d) ... potentials for adapting the physical design (which code parts should
> be located in which header?, do we need new header files?, etc.)

Thanks a lot for bringing ideas on the table! Indeed it is more than
time to do so.

>
> For me, the discussion of a) is desirable, since it is affecting the library
> all over.

OK for a), I'm pretty sure that we're getting it essentially right but
your bug #82 suggests that some more thinking might be needed :)

>
> With the discussion of b) I hope to improve the general maintenance time
> which is beneficial for the developers already working with the Eigen core
> and beneficial when it comes to attracting new core developers.

Sure!
Any specific idea?

I have one in mind: the template logic to dispatch between all the
product types: files such as ProductBase.h and Product.h. It's already
quite good but it has continued to evolve and I'm sure that it could
now use another pass of global reorganization. That would hopefully
also solve the mystery of why products take such long compilation
times to instantiate. Anyway, I'm all for going quickly through such
items during the meeting and noting them on a wiki page, but let's not
attempt to fix all that during the meeting as that would take far too
long!

>
> The point c) ... well, it's related to a) and b). Unifying the access to
> class properties (traits) has the chance of improving readability and
> navigability.

The biggest purpose of ei_traits<...> is forward-declarations.
Actually, at some point, I named it ForwardDecl<...>. The idea is that
with our CRTPs, when we want to access Derived::SomeTypedef from
MatrixBase<Derived>, we can't, because Derived isn't fully declared at
that point, so we put SomeTypedef instead in ei_traits<Derived>. Does
that help? Should ei_traits be renamed?

> And finally, d) is again related to readability and maintainability. It's
> ugly spade-work but might help.

Again, good point, anyway: let's keep your list for the meeting and go
over it, i'm sure it will generate an interesting discussion!

>
> Any comments on these proposals?
>
> And yes, I am aware that they are not necessarily required to quickly get
> to 3.0 but somehow I think they are still of interest.

Agreed,

Benoit