Re: [eigen] problem with operator() in development branch

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

(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

    A.row(i).cwiseProduct(B.col(j).transpose()).sum()

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
> assertion.

If you don't agree to make them public, then yes a good static assert
message would help a lot.

Benoit