Re: [eigen] Eigen2 in Avogadro

["Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>]

On Tue, Aug 26, 2008 at 11:35 AM, Daniel Gómez <dgomezferro@xxxxxxxxx> wrote:
> On Monday 25 August 2008 21:38:23 jacob@xxxxxxxxxxxxxxx wrote:
>> Quoting Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> > good to know. Daniel (aka cylmor), are you still interested by hacking
>> > the Sparse module ? this might gives you a hint on what to do first !
>> > actually our dense and sparse matrices already fulfill the storage
>> > needs. Beyond polishing the Sparse API, what's really missing are the
>> > high level solvers...
>>
>> Daniel: if you are interested then don't hesitate to contact the Step
>> guy directly: ks vladimir at gmail.
>
> Sure, I'll contact him and see what I can do. I've already been looking at the
> code and they seem to be using their own implementation of a Vector2d, that
> is used even more than gmm stuff. May be you can have a look to see if it's
> worth porting it to eigen2.

Excellent ! Indeed they have their own vector class, seeing their API,
the change would be trivial though.

> They also use some wrapper classes around std::vector and plain C arrays
> (gmm::array1D_reference for instance). Should these be made VectorXd ?

if the purpose is to warp std::vectors, then I would say:
Map<VectorXd>(&v[0], v.size())

>> About solvers, one quick solution is to borrow code from gmm and to
>> ask permission to relicense from LGPL2 to our LGPL3+/GPL2+. I know the
>> GMM maintainers are helpful.
>
> I'll try to implement them myself, if its too inefficient or too difficult
> I'll contact GMM developers.

that's up to you ! but I would advocate too to reuse their algorithms,
at least for the first step...

> I think what's left from eigen is to retrieve rows/columns from a sparse
> matrix, but it doesn't look too difficult to do.

yeah I think generic blocks are already supported, but indeed for
sparse matrix it is worth it to have a dedicated implementation of row
and col.

There is also a more general issue I would like to point out:

we have:

MatrixBase <- SparseMatrixBase <- SparseMatrix
                                                 <- HashMatrix
                                                 <- etc...

let's imagine we want to redefine .row(int) for SparseMatrix (or
SparseMatrixBase), then what about:

(1)    (m1 + m2).row(i);

though (m1 + m2) has the Sparse flag, .row(i) will use the generic
default implementation.

of course this example should be rewritten:

(2)    m1.row(i) + m2.row(i);

ok, with sparse matrix, even if the proper .row(i) would be called,
you should really write (2) instead of (1), but still, this is a
general  issue which probably does not hold for row/col only...

FYI, for solveTriangular and Product I handled this problem with
internal template specialization of ei_solveTriangular_impl and
Product (and same for eval btw), maybe the same technique can be
applied everywhere special code for sparse matrices is needed...

Another related thing: I guess that several methods of MatrixBase does
not hold for sparse matrices... then if the need appear, perhaps one
option would be to simply have:
SparseMatrixBase <- SparseMatrix
                            <- HashMatrix
                            <- etc...

and copy from MatrixBase to SparseMatrixBase only the subset of the
needed features... let's see....

> I hope you'll be around to answer questions, otherwise I'll be stuck
> forever :P

yes, sure no problem !

gael.