aboutsummaryrefslogtreecommitdiffhomepage
diff options
context:
space:
mode:
-rw-r--r--TODO78
-rw-r--r--doc/Mainpage.dox11
2 files changed, 10 insertions, 79 deletions
diff --git a/TODO b/TODO
deleted file mode 100644
index 3736c24ba..000000000
--- a/TODO
+++ /dev/null
@@ -1,78 +0,0 @@
-Things that need to be done for 2.0:
-
-The Core modules is essentially ready. Now we need more modules:
-- QR decomposition
- -> ANY VOLUNTEER? I can provide a scanned copy of Golub&vanLoan.
- -> investigate various algorithms, balance numerical stability vs. speed,
- maybe go for a different algos for fixed-size (small) vs. dynamic-size
- (typically bigger).
- -> applications: eigenvalues, eigenspaces, operator norm...
- -> more applications: by computing eigenvalues of a companion matrix,
- we can provide a general polynomial solver. I can explain that to
- a potential volunteer... also this is optional.
-
-- SVD decomposition
- -> ANY VOLUNTEER?
- -> Same remarks as for QR.
- -> applications include pseudo-inverse and linear regression (in Eigen1 we
- did linear regression with LU but that was not very good).
-
-- Array
- -> ANY VOLUNTEER?
- -> We should group in this module all the functionality that consists in
- abusing a matrix as an array. Many people have asked for such
- functionality:
- -> coefficient-wise product (a.k.a. "Schur product" of matrices).
- This should return a new expression. Look at Core/Sum.h for a starting
- point.
- -> Apply some function (such as "exp") to every coefficient of a matrix.
- This should return a new expression. Look at Core/Conjugate.h for a
- starting point.
- -> stack matrices horizontally and vertically to form larger matrix
- expressions. Look at Core/Block.h, Core/Minor.h for a starting point.
- -> sum over the elements of a vector (look at Core/Trace.h to get
- a starting point).
- -> Given a matrix, return a vector whose i-th coefficient is the sum
- of the coefficients in the i-th column of that matrix. Same for rows.
- -> This should return an actual vector (i.e. evaluate immediately),
- not an expression, because a loop is involved.
- -> Yes, this can be done as "matrix * VectorType::ones()" but we
- should implement it separately so as to not be too hard on the
- compiler.
-
-- Gaussian elimination
- -> LEAVE IT TO ME as I did something similar in Eigen1.
- -> I don't call this module LU because I want to code certain operations
- such as inverse in an optimized way that bypasses the LU decomposition.
- But yes, LU is one of the things that will be provided by this module.
- -> Other things to do here: determinant, basis of kernel, basis of range,
- antecedent etc...
- -> Should be do a "simple linear solver" like in eigen1? Did anybody
- use it?
- -> linear regression should use SVD instead. However as a temporary
- solution we could borrow the implementation from eigen1, using gaussian
- elimination.
-
-- Geometry
- -> LEAVE IT TO ME as I did something similar in Eigen1.
- ->low-dimensional geometry (quaternions, cross product, rotations)
- ->projective geometry(opengl matrices, Qt matrices)
- ->euclidean geometry (Gram-Schmidt)
-
-- Sparse objects support, by wrapping GMM++
- -> ANY VOLUNTEER? I'm looking at the folks already used to GMM++. I will
- provide support but am not used to GMM++ so wouldn't like to have to do
- all that alone.
- -> Goal: provide a nice wrapper around GMM++ with Qt-style copy-on-write
- (I can code the copy-on-write part if you don't want to do it)
- -> Very important for Krita 2.1 and Step
- -> No expression templates here. So the API won't be quite identical to the
- rest of Eigen. Should be release under a different name? "Speisen" comes
- to mind ;)
- -> No need to wrap all of GMM++. Only sparse objects. Only what's useful
- for KOffice 2.1 and Step (if you want more, do it).
- -> Step uses:
- -gmm::cg, constrained_cg
- -dantzig algorithm
- -types: gmm::row_matrix, col_matrix, rsvector, array1D_reference
- -> What is needed for Krita?
diff --git a/doc/Mainpage.dox b/doc/Mainpage.dox
index e6f5e60a6..29ee996eb 100644
--- a/doc/Mainpage.dox
+++ b/doc/Mainpage.dox
@@ -4,6 +4,7 @@ o /** @mainpage Eigen
<a href="#overview">Overview</a><br/>
<a href="#license">License</a><br/>
<a href="#features">Features</a><br/>
+<a href="#todo">To-do wiki</a><br/>
<a href="#compiler_support">Compiler Support</a><br/>
<a href="#news">News</a><br/>
<a href="#download">Download</a><br/>
@@ -39,16 +40,24 @@ Here are general features of Eigen and more specific features of the Core module
<ul>
<li><a href="http://ubiety.uwaterloo.ca/~tveldhui/papers/Expression-Templates/exprtmpl.html">Expression templates</a> everywhere. This is an optimization (elimination of temporaries, lazy evaluation), but more importantly this allows for a much nicer API, especially as Eigen supports lvalue expressions. For example, the following is valid with Eigen and compiles to optimized code:
\code matrix.row(i) += factor * matrix.row(j); \endcode</li>
- <li>Both fixed-size and dynamic-size objects are supported, in a way that allows Eigen to make
+ <li>Both fixed-size and dynamic-size objects are supported, with uniform API,
+ in a way that allows Eigen to make
all usual optimizations in the case of fixed size, such as loop unrolling.</li>
<li>Both column-vectors and row-vectors are supported, as special cases of matrices.</li>
<li>The following scalar types are supported and well tested: \c int, \c float, \c double,
\c std::complex<float>, \c std::complex<double>. </li>
</ul>
+<a name="todo"></a>
+<h2>To-do wiki</h2>
+
+The To-do wiki for Eigen is here: <a href="http://techbase.kde.org/index.php?title=Projects/Eigen/TODO">http://techbase.kde.org/index.php?title=Projects/Eigen/TODO</a>.
+
<a name="compiler_support"></a>
<h2>Compiler Support</h2>
+Eigen is standard C++98 and so should theoretically be compatible with any compliant compiler. Of course, in practice, things are slightly different.
+
Eigen is well tested with recent versions of GCC and gives very good performance with GCC 4.2. For some reason the performance is not so great with GCC 4.1.
Eigen is also well tested on ICC, and gives even better performance with it than with GCC 4.2.