Re: [eigen] restarting |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] restarting*From*: Benoît Jacob <jacob@xxxxxxxxxxxxxxx>*Date*: Sun, 2 Sep 2007 22:23:09 +0200

Hi Ben, On Sunday 02 September 2007 21:38:14 Schleimer, Ben wrote: > Congrats on the decision to restart eigen2. Sounds like a good direction > to take. You might want to consider building unit tests for the framework > before you write the code because then the framework will be much easier to > debug. Thanks. I'll for sure write unit-tests simultaneously with the library code. The new eigen2 is progressing quicker than I expected. For now the "library" does only matrix-matrix product, as this is a good starting point for expression templates. I'll commit to /branches/work/eigen2 as soon as I have got the basics right. Already two things are nice: 1) reusing the CRTP trick from Eigen 1, I treat on an equal footing both fixed-size and dynamic-size (dense) matrices. The expression templates don't need to be written twice. (TVMET did only fixed-size). Only sparse matrices won't be able to share these expression templates. For these I'll either write special ETs or go for copy-on-write instead (still not sure). 2) My expression templates should be able to represent lvalues. For example, I'm confident that Eigen 2 will allow magic things like: matrix.row(i) += matrix.row(j) to operate directly on rows and columns, without any overhead. TVMET didn't allow that. > What was the complexity that TVMET added which eigen2 doesn't need? * Automatic type promotion. Eigen1 didn't do it and nobody complained about that. Moreover it adds an overhead when it occurs (casting between types). * Ability to apply standard math functions to every coeff of a matrix/vector. This had to be defined for every math function, so it generated a lot of code and caused compatibility issues. * Ability to apply STL algorithms to a matrix/vector. * Meta-code determining at compile-time whether or not to unroll loops using metaprograms, based on the size of objects (we'll always unroll for fixed-size objects, as anyway they're intended for small sizes only. Still not sure whether we need meta unrolling, as in Eigen 1 we did quite well without that). * Utility code like a timer for benchmarking. Was out of place here. * Lots of #ifdef making platform checks at compile-time (they are better done at install-time by CMake) and sometimes testing for trivial things (like avaibility of std::complex<T>). * and lots more.... Cheers, Benoit > > Cheers > Ben

**Attachment:
signature.asc**

**Follow-Ups**:**Re: [eigen] restarting***From:*Schleimer, Ben

**References**:**Re: [eigen] restarting***From:*Schleimer, Ben

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] restarting** - Next by Date:
**Re: [eigen] restarting** - Previous by thread:
**Re: [eigen] restarting** - Next by thread:
**Re: [eigen] restarting**

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