|[eigen] Question about the class hierarchy|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: [eigen] Question about the class hierarchy
- From: Manoj Rajagopalan <rmanoj@xxxxxxxxx>
- Date: Wed, 30 Jun 2010 00:07:30 -0400
- Organization: EECS Dept., University of Michigan, Ann Arbor, MI, USA
Hi eigen developers,
I have been a little uncomfortable with the fact that EigenBase is
most-derived common base class for various types of matrices and that to
handle arrays, DenseBase inherits from EigenBase.
I am still learning Eigen and am not 100% familiar with the internals but I
present my thoughts here at least for my learning if not as remarks on the
1. Aren't Array and Matrix independent *concepts*? Therefore, a dense matrix
expression, which shares traits with an array expression should inherit both
an Array base class and a Matrix base class simultaneously using multiple
inheritance as opposed to the linearized inheritance in Eigen.
2. Other matrices should inherit this Matrix base class. Then all matrices
can be handled with matrix semantics using one base class without having to
worry about intervening array semantics - this is what makes me most
uncomfortable. For example, take solve() methods which accept const
matrix-expressions as arguments. Therefore, they should accept
DiagonalMatrix/Wrapper, SparseMatrix etc. If the solve() prototype is
declared with MatrixBase<OtherDerived> const& as arg then we rule out this
possibility. On the other hand, if we declare it with EigenBase<...> const&
as arg, then it also allows Array expressions to be passed. the latter is not
a problem if we allow it and warn the user to guard against this caveat but
still conceptually Arrays are distinct from Vectors/Matrices ...
3. If the Array base and Matrix base must inherit EigenBase then this
inheritance must be virtual so that there is exactly one copy of EigenBase in
the derived object. virtual inheritance works with templates at least with
gcc 4.2 on my linux machine.
4. EigenBase seems to contain member functions that internal documentation
warns against using. Equivalent code seems to be present in eponymous member
function definitions of the derived classes. Then, if this makes the
EigenBase member definitions redundant and we can remove them, this leaves
very little in EigenBase itself - just a few methods like rows(), cols(),
size() etc. Are we keeping these redundant definitions just so that we can
avoid re-declaring all of these methods in the derived classes?