Re: [eigen] Sparse usage feedback |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Sparse usage feedback
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 15 Oct 2010 21:28:47 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=FQMJtN7WwdMvCdaGLl/VMOYeJ2QkArA+bAvAs45XH4k=; b=ieeGH7HoOvNmZ37gj2wd7UzRlc2eRFHQQDsHbVe1xoyazZR7vOdkcE25zO9cElervr lkdgqvwjMm0CsLudCyccOLnfBEkCxAa1vSEvZJWfnFzOfAIG5A1FTv4S2dMdsoXif+Vf DDVKD5oKw2LUc6xonRhsSLCYGM1p/3gvxgEpM=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=CFMxupCkTRdYdFIbsqcR8BhCOXgtJdniOGASCdhlTGRQ+MJ2RZ+F6pwfJOw8/1Di1l 3eIwbrsVJi0TOh7m4NAkA2tyWorxtV+aiYOVSzSdluGBUgSTstIdKb1ym32RJFZWXEFa edGZiSW5hzU8nLTR8aeu3R6LPSyehJekmTfIU=
Hi Bernard,
thank you for your feedbacks on the sparse module, it's always very
appreciated as I often feel a bit alone here...
On Fri, Oct 15, 2010 at 5:22 PM, <bernard.hugueney@xxxxxxxxxx> wrote:
> 1°) The iterators feel java-ish :
>
> «for(SparseMatrixType::InnerIterator it(mat,k); it; ++it)»
>
> I'd have expected to be able to get a begin() and an end() iterator
>
> instead,
>
> as is conventional in C++ (cf. STL).
I could consider to give it a try if and only if the begin()/end()
paradigm would bring any additional benefits than just being closer to
the STL. The current approach has the advantage to be simpler to use
(e.g., no need to declare an end iterator). Well, actually I'm
thinking that having an access to the end() might be useful but I'm
still a bit worried about the performance and the API verbosity.
Here is an example of what could be the API:
SparseMatrix m;
for(int j=0;j<m.outerSize();++j)
{
SparseMatrixType::InnerIterator end(m.innerVector(j).end());
for(SparseMatrixType::InnerIterator it(m.innerVector(j).begin());
it!=end; ++it)
...;
}
> 2°) The iterator do not expose row() and col() through an iterator
>
> interface
>
> (i.e. with operator*()) which make it impossible to manipulate sequences
>
> of
>
> coords with the standard algorithms operating on iterator sequences.
Sorry, but I don't really understand what you are looking for here,
can you be more specific please?
> 3°) This is not possible to construct a Sparse from a Dense
>
This is already possible:
sparse = dense.sparseView();
sparse = dense.sparseView(ref,epsilon); // skip coefficients smaller
than ref*epsilon
> 4°) I think some scalar operation traits are missing
>
> (i.e. trying to multiply an int matrix with a double fails to find
>
> ‘struct Eigen::ei_scalar_product_traits<double, int>’ )
This is because this is explicitly not allowed. You have to explicitly
cast the int matrix to double. Our opinion is that such an automagic
cast would be dangerous.
> 5°) I think that the typedefs in i.e. SparseLU<> should be public
>
> I may need to know the LMatrixType & cie to make some metaprogramming of
>
> my own
>
> (or did I missed some traits struct ?)
Yes you are right. All these decompositions/solvers require a lot of
polishing, and actually I've already started a rewrite of them with a
slightly simpler/safer API. The main change is that I'm removing these
Backend template parameters.
> However, I do want to state that these annoyances were really minor and
>
> that working with Eigen is an overall very good experience : many thanks
>
> for the hard work ! :)
thank you.
gael
>
>
> Best regards,
>
>
>
> Bernard
>
>
>