[eigen] Question about the class hierarchy

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

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 
API design.

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?


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