Re: [eigen] patch for tridiagonal matrices in eigen

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

Hi Mauro,

2009/1/8 Mauro Iazzi <mauro.iazzi@xxxxxxxxx>:
> Hi, sorry for replying so late.

No worry at all since we're in the rush to release 2.0 we don't have
much time at the moment for thinking about this either...

I'll study carefully your mail later, when I have time; for now I just
want to address this quick point:

> 2008/12/30 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>>
>> An expression class MyExpression is a bad idea whenever the
>> MyExpression::coeff() method is slow and in practice it can be
>> bypassed when implementing actual algorithms.
>>
>
> It's a perfect criterion. However, when something else than an
> expression is used, memory may be wasted. This is quite a concern with
> me: a single matrix storage may be the few hundred megs that exceed my
> memory and start using swap. I have no obvious solutions.

When I said that we should avoid expressions, I didn't mean that we
should instead represent as a plain old n*n matrix, storing the
coefficients!
Instead, when I suggested that we should have a special "diagonal
matrix" type, I really meant just a wrapper around the vector of
diagonal coefficients. So the storage is really optimized.
What meant then, is that some operations that make sense on
expressions are very inconvenient to optimize for this kind of storage
-- e.g. coeff(int,int) needs to do a runtime if(row==col) that is very
slow.
What I proposed then, was to completely give up the idea of having
these diagonal matrices as expressions -- instead have just this
wrapper around the vector of diagonal coefficient plus a few methods
that make sense and are optimized for diagonal matrices. For example
for diagonal matrices, there would be an operator* implementing
optimized diagonal product. There are many more operations that one
_can_ implement but it doesn't mean we should; for example
eigenvalues() is trivial to implement for a diagonal matrix but there
is no point in doing that, for by the time the user calls such a
eigenvalues() method, he already knows the result. So my point was
that perhaps we could without loss of usefulness restrict the special
matrices (like diagonal matrices) to just optimized storage +
optimized nontrivial algorithms and give up having them as ordinary
Eigen expressions.

Then Gael replied, he seems to insist on having them as expressions,
and I haven't had time to far to give it a new round of thinking. All
I know is that we'll mark asDiagonal() as experimental in the 2.0
release to leave us full freedom to change everything about it in 2.1.

Cheers,
Benoit

---