[ Thread Index |
Date 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=;
Hi,
--- 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
> Matrix/MatrixX/Vector/VectorX.
>
> It is now possible to "evaluate" expressions, i.e. you do
> eval(some_expression)
> 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.
Cheers
Ben
>