[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] update
- From: "Schleimer, Ben" <bensch128@xxxxxxxxx>
- Date: Wed, 26 Sep 2007 12:11:54 -0700 (PDT)
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=CrvanWteTxIKnCu3igQUP7DiYoFF+QV69v2n/B5U8eL/sgjaU1GAJ0usDQWUSFlNm0JO8Hleav+8LJvo3e3LnpxFf2qdLKwedaCj8jM/SZGE+7aygsego/mUgP8So/ik5853DPaUW+NwGRvcC1Ds2SsDLRJC5beEDHDcU8pWaPQ=;
--- Benoît Jacob <jacob@xxxxxxxxxxxxxxx> wrote:
> Hi List,
> I thought that i'd focus on my "real" job but didn't manage to ;) so here's an
> update on what happened, and wish me to manage to focus on my job now!
> I've been working locally with git and git-svn for the past 2 weeks, because I
> had really big changes in mind. I've completely refactored eigen2, and the
> most obvious result is that there are now only 714 lines of code, down from
> 1093, and we don't even use anymore those big preprocessor macros to define
> operators -- so the code size drop is even bigger!
Wow, nice. Thats a pretty huge drop. Nice job. I guess we'll have plenty of design wiggle room for
implementing specific optimizations...
> Concretely, I've unified MatrixXpr and MatrixBase into a single base class
> template, EigenBase. This way, one can declare/define a function f taking any
> kind of matrix/expression/vector/whatever as follows:
> template<typename T, typename U> f(EigenBase<T,U>& m);
> while the former design forced to define f separately for expressions and for
> actual objects. This is responsible for the larger part of the code size
> drop. Of course this is a "curious" base as in the CRTP programming pattern.
Very nice. Can you give a quick example of f?
> There are no longer Matrix/MatrixX/Vector/VectorX classes each reimplementing
> its own constructors etc. There is only one "Matrix" class (it's what used to
> be called MatrixBase), and there are typedefs emulating
> It is now possible to "evaluate" expressions, i.e. you do
> and some_expression automatically finds which Matrix type must be created.
> This means that all our expression types now recursively remember the number
> of rows/columns as a compile-time constant, with a magic value (currently -1)
> meaning dynamic value (unknown at compile-time). This will be very useful
> later when we implement heavy operations which need to create matrices --
> such as LU decomposition.
Wow, how did you achieve this black magic? Seems extremely cool though.
> PS Bensch: I know you won't like eval() being a global function, but I've yet
> to find a way to make the compiler tolerate it as a member. Probably that's
> doable, I'm just tired.
Well if eval is applicable to all eigen expressions, then I don't see why it shouldn't be in the
Eigen2 namespace and be done with it. It seems reasonable for it to be general, especially if it
used for different expressions.