|[eigen] Re: RFC: Eigen 2 design|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: "Benoît" Jacob <jacob@xxxxxxxxxxxxxxx>, eigen@xxxxxxxxxxxxxxxxxxx
- Subject: [eigen] Re: RFC: Eigen 2 design
- From: "Schleimer, Ben" <bensch128@xxxxxxxxx>
- Date: Wed, 25 Apr 2007 15:13:42 -0700 (PDT)
- Cc: Tommi Rantala <tommi.rantala@xxxxxxxxxxxxxx>
- 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:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ne09v1qOCRUBi8OrmEwoLzik5+qnHYnddnNirpZ5NCHkLkemCmTmT6yr6xJYJXN7fMyQE91ShByY3N2sb1/8tclg5tnpxxwt/YK8jZ/xhp4NA+cGiE64+oPhVExJngHT/TZPAgYTBZv3ct7oHy2YY/28D2nDDyf+44o9aSryykQ=;
> - eigen-basic will do only fixed-size. It will reuse the Eigen1 code, but
> specializing it to fixed-size-only. No "curiously recursive template pattern"
> anymore. It will allow rectangular matrices. Eigen-basic is the part that
> will be used the most in OpenGL apps, games, etc. Low-level optimizations
> like SSE are most welcome here.
Sounds great. Are you going to have different sized matrices/vectors (2,3,4) or use expression
templates and have just one matrix and one vector class. Check out the TinyVector class if you're
going for the second option. If might help you...
> - eigen-gmm will be a wrapper around GMM , providing dynamic-size (both
> dense and sparse representations). By reusing GMM we avoid of course the hard
> work. The value-added of wrapping it is that GMM has a pretty spartan C-style
> API, with not even arithmetic operators. The reason why the GMM authors
> decided to do so, is that arithmetic operators return objects by value, which
> causes a deep copy, which is slow. I have the feeling that we could implement
> copy-on-write as in Qt, and that that would solve the problem here. It would
> be almost as efficient as expression templates, without the hassle for the
> programmer and the compiler.
Copy-on-write with arithmetic operators... sounds really nice...
> There will be ways of converting between the various matrix and vector types,
> including ways of converting between fixedsize (eigen-basic) and dynamic-size
> (eigen-gmm). Probably in the form of conversion constructors and operators.
> The Eigen package should contain both eigen-basic and eigen-gmm, but it should
> also be possible to release eigen-basic as a standalone package.
> GMM should live in a subdirectory of its own and be usable directly by apps
> wanting it.
> Eigen-gmm can't reuse GMM by inheritance, if only because we want to implement
Perhapse, the eigen-gmm matrix needs to have-a gmm matrix and internal copy-on-write checking...
> Thus there's a lot of work to do here, and help is welcome :)
Ask and we will come if there is time. Which there is too little of right now. :(