Re: [eigen] [PATCH] Toeplitz matrix specialization

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

Very good idea, i was thinking of doing exactly the same!

2009/1/29 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> Hi,
>
> to start the debate I put some thougths on the wiki:
> http://eigen.tuxfamily.org/index.php?title=SpecialMatrix
>
> 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
>>
>>
>>
>
>
>