|Re: [eigen] problem with operator() in development branch|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] problem with operator() in development branch
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Tue, 1 Jun 2010 08:06:42 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=Le354/k2ai0i94Tm5n6vvEmANHbtu2ilFXJOPKklNKs=; b=TcylVOtmykLlZJSNx2Z0C5ouAx/J0+RJUt4YyeDXQ1sziHccJoWYwUIHe/sNg/dDaB 9B1UiDh7A/zgJHaJNTvOT06Q37mkyr4SngwOtVUem0F2/QMZXNU6r+maKqQOjaNHksh/ cjFBjLYUFY8DJEGrHWkShjauB5l/d5begcTNg=
- 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; b=qgFXIuz52m4+gr5GWqyHJ+VVWJij8w+TljP2d2BKEir+O9dIT8bU5yEDHcCJ6G875H SrukIhOa/051KH3zF/FtVj56tQrEtkPcYqVW/mQOnQxw4867aDTyYcCgEqvLkJCrnMwJ sw4P01zHQVfWPfpJbGHFOzno4nNtk1W5sRLkw=
(oops, Gael, you'll receive this twice)
2010/6/1 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> ok, the pb is that's quite dangerous to offer coeff-based access because we
> want to make sure that such a product expression is never used by any
> coefficient based algorithm. Of course, in the above example, there is only
> one access, so it is fine, but think about a user code doing a manual loop
> on a general DenseMatrix...
ok, I understand your concern, but it can be addressed by a unit-test.
Why not add a EIGEN_NO_COEFF_ACCESS_IN_PRODUCTS option making them
private, or static-asserting, and then add a unit-test to check that
in practice it's not being used when doing D = A*B+C ?
> On the other hand, ProductBase has to inherit DenseMatrix to make it
> compatible with all high level operation as in A*B+C...
> To be honest I don't see any use case for doing coeff based accesses on a
> product expression.
Doing (A*B)(i,j) is just a funny shortcut for
although of course in the real case it's not too bad: A.row(i).dot(B.col(j)).
It's a nice luxury that we can afford, having expression templates. It
is one of the examples it think of naturally when I want to show off,
until I think, "oh wait! but this one doesn't work with eigen!"
So I agree that it's not a big necessity, but it's nice to have.
> Perhaps I can try to make the compilation error more explicit using a static
If you don't agree to make them public, then yes a good static assert
message would help a lot.