Re: [eigen] [PATCH] Toeplitz matrix specialization |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] [PATCH] Toeplitz matrix specialization
- From: Keir Mierle <mierle@xxxxxxxxx>
- Date: Thu, 29 Jan 2009 10:55:45 -0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Zw4J5ZuB54AYgVBzZjy8WYVYa7ewvWIQxmP+xGn94eg=; b=rmN+OsxXsR0UD316oE0sXc8vXLw/yaKrMPBe/TttNQtuPC5n52Xsj6evjvHhtMqhf3 7qI39I9jkumqbXDJ+IrYVe7BZNjVJfgVhA0bCqpvEp0ENDxAIz51OrUlCRcnjQBDcbvn HIasrK7OR2Zeap+nrQSH5BJeEveiufjwyYQSY=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=ik07/T+HKIlzeqJ2xVTGwCTCC2Iz8AJMqbdhvodDS9BNAt9zR5v92hvbOcR6nHwekd x8vv54+crCW+YlE+5zYubPKBYOfXLl91NWE/gSF486e1kMAwE3AP1TrbZ/jqezkzCLKq vEIekoU/qswld0HBFjayVmsix4LvTbezzc6hM=
On Thu, Jan 29, 2009 at 6:40 AM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> Hi,
>
> to start the debate I put some thougths on the wiki:
> http://eigen.tuxfamily.org/index.php?title=SpecialMatrix
The idea of making solveTriangular into Part::solve() sounds good to
me. Right now the hetergeneous API for solving triangular systems is
unfortunate. I vote to have solve() work as expected for triangular
matrices with the same API as LU::solve, SVD::solve, QR::solve, etc
(i.e. MyVec x; bool succeeded = my_triangular_mat.solve(b, &x);).
Perhaps mymat.upperTriangular().solve(...)?
Is there an excessive runtime cost to detecting a singular matrix in
the triangular solver?
Keir
>
> Gael.
>
> On Thu, Jan 29, 2009 at 2:08 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> 2009/1/29 Mauro Iazzi <mauro.iazzi@xxxxxxxxx>:
>>> Hi, I'm still thinking about that...
>>> Is there any new idea on how to handle this problem?
>>>
>>> On a side note, wouldn't it be nice if sparse matrices were in the same class?
>>
>> Yes we had a quick discussion over IRC yesterday, and yes we evocated
>> the idea that these special matrices were often sparse and then they
>> should be designed with interaction also with Sparse in mind.
>>
>> Here's the log:
>>
>> [mer. janv. 28 2009] [18:23:03] <ggael> I'm thinking about the
>> SpecialMatrix mess with Special in {Diagonal, Tridigonal, Toeplitz,
>> Band}x{Normal,SelfAdjoint}.....
>> [mer. janv. 28 2009] [18:23:32] <bjacob> good that you're thinking
>> about that in such generality
>> [mer. janv. 28 2009] [18:23:35] <ggael> and I don't have an elegent
>> solution yet :(
>> [mer. janv. 28 2009] [18:24:24] <bjacob> i still am tempted by the
>> brutal solution of giving up having these as MatrixBase expressions...
>> [mer. janv. 28 2009] [18:25:14] <bjacob> they are as special as
>> SparseMatrix (many of them are actually sparse matrices)
>> [mer. janv. 28 2009] [18:25:28] <ggael> the main problem is the
>> explosion of combination.... (unless we give up about perf and keep
>> branching inside coeff())
>> [mer. janv. 28 2009] [18:26:04] <bjacob> that only is a problem if you
>> want to allow all sorts of operations seamlessly on these matrices
>> [mer. janv. 28 2009] [18:27:12] <bjacob> the problem goes away if we
>> only support these matrices as stupid containers for communicating
>> with algorithms (we'd still allow operator= on them to copy into a
>> MatrixBase, but that's all)
>> [mer. janv. 28 2009] [18:27:37] <bjacob> e.g. tridiagonalization would
>> return a TridiagonalMatrix that's just a struct with a few vectors
>> [mer. janv. 28 2009] [18:27:47] <bjacob> then you could do MatrixXd m = tridiag;
>> [mer. janv. 28 2009] [18:27:49] <ggael> yes, for Toeplitz this would make sense
>> [mer. janv. 28 2009] [18:28:49] <bjacob> i don't think there's much of
>> a use case for e.g. multiplying a tridiagonal matrix by a diagonal
>> matrix
>> [mer. janv. 28 2009] [18:29:05] <bjacob> so we only need to let each
>> special mat type interoperate with MatrixBase
>> [mer. janv. 28 2009] [18:29:16] <bjacob> but we don't need to let them
>> interoperate with each other
>> [mer. janv. 28 2009] [18:29:28] <bjacob> so O(n) stuff not O(n^2)
>> [mer. janv. 28 2009] [18:30:51] <ggael> ok, then that would be doable
>> without too much work
>> [mer. janv. 28 2009] [18:31:13] <bjacob> yep
>> [mer. janv. 28 2009] [18:31:50] <bjacob> something just occured to me
>> [mer. janv. 28 2009] [18:31:51] <ggael> also Toeplitz => special
>> module, too specific !
>> [mer. janv. 28 2009] [18:32:18] <bjacob> these special matrices would
>> be actually not closer to MatrixBase than SparseMatrixBase
>> [mer. janv. 28 2009] [18:32:43] <bjacob> we should probably right away
>> think of letting them be useful also for Sparse
>> [mer. janv. 28 2009] [18:33:58] <ggael> yes of course
>> [mer. janv. 28 2009] [18:34:31] <bjacob> i hope that what i just said
>> doesn't contradict your latest big commit (haven't looked yet)
>> [mer. janv. 28 2009] [18:36:27] <ggael> no, what my commit mainly did
>> is to add: DiagonalMatrix<Scalar,Size>, it currently inherits
>> MatrixBase but that can be changed later
>> [mer. janv. 28 2009] [18:37:14] <bjacob> ok
>>
>>
>>
>
>
>