|Re: [eigen] patch for tridiagonal matrices in eigen|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] patch for tridiagonal matrices in eigen
- From: "Benoit Jacob" <jacob.benoit.1@xxxxxxxxx>
- Date: Thu, 8 Jan 2009 20:23:39 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=j5s7/wgCUuBTpTRzTLZP/YIIUyah2MyYY/C3wA1Sceg=; b=dVYFWhrW6QEvKHK+AKEyl8wGzAXFFxB2OZTT8N7AeXUNM0A0fsCd9VC1BDxlrKlnNT DHxUX+LiA2GwN6gkhVEl5ECSkwdmJFc+LuHnM3uo1JWPHSsJC0fhB9Jnaa+ZIYNnU60J I0SEnt3cbELidlNxZOm+Bz5hdGufmXjC8v7Sg=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=J/B9Vt5kXo5QjGA/BnC4r2BD9buI3K8ApR6fjMgNwWUMu6HnTBnxeDQktEfn4J5t1i /t0uVgadRlpMFucnDiKXP0E4xv7lD3jHfO9LE1jmE2fTU0Wmpa0Z1znvaCn4vVKHkMCJ RfelalfpZAu85cfk6CUVbdwTwRVuBe45q4o+A=
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
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
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
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.