[eigen] Re: special matrix classes: template parameters

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

argh.

i think i'm not going to make this change after all. It feels too
weird to have these special matrix classes relying on a dense matrix
class. It seems better after all to keep the different base matrix
classes on an equal footing.

instead i'll add "AtCompileTime" parameters... even though they only
are useful for the toDenseMatrix() method. at least that will be
homogeneous with Matrix

Benoit (very frustrated)

2009/11/14 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> further remarks:
>  - this reallows nice simplifications in the code (in ei_traits and in typedefs)
>  - while i'm at it, i'll let the toDense() methods use a ReturnByValue
>  - and I'll rename ReturnByValue to ReturnValue since that's what it is
>
> i put that on the TODO and i take care of it now.
>
> Benoit
>
> 2009/11/14 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> (and the same applies to DiagonalMatrix, of course, and to
>> PermutationMatrix that i am coding at the moment)
>>
>> 2009/11/14 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>>> Hi,
>>>
>>> Currently the BandMatrix class takes Scalar, Rows,Cols template
>>> parametes that could be replaced by a single parameter DenseMatrixType
>>> representing the return value of toDense(). Not only this would allow
>>> to simplify the template parameters considerably, this would also be
>>> more future proof (it could read more data from the DenseMatrixType),
>>> and would allow to benefit from the MaxRowsAtCompileTime notion (for
>>> dynamic-size-inside-fixed-size-storage --- that is required to ensure
>>> "no malloc with fixed-size objects" in complicated use cases).
>>>
>>> So OK to let it take a DenseMatrixType template parameter instead? And
>>> in the Options, the RowMajor stuff would also move there, so that's a
>>> further simplification.
>>>
>>> Benoit
>>>
>>
>