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

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

Gael: you sent the e-mail to me only!

2010/6/1 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>
>
> On Tue, Jun 1, 2010 at 2:05 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> 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 ?
>
> actually I was also worried about "wrong" user code, not only our own.
>
>>
>> >
>> > 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()
>
> (A.row(i) * B.col(j)).value()
>
>  works as well.
>
> or
>
> (A.row(i) * B.col(j))(0)
>
> or
>
> (A.row(i) * B.col(j))(0,0)
>
> and even a simple
>
> A.row(i) * B.col(j)
>
> could work by adding a conversion operator to Scalar in the inner-product.

oh, right ! Don't know why I didn't remember about that. By the way,
are you planning to allow 1x1 to scalar conversion ? I'm rather
favorable to that. There recently was an unanswered forum post about
doing that.

>
>
>>
>> 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.
>
> yes I know... and I'm a bit puzzled...
>
> Is it really better to allow (a*b)(4,6) and at the time allow very slow code
> like:
>
> template<typename T> void foo(const DenseBase<T>& m) {
>  for(int i=0; i<m.rows(); ++i)
>  for(int j=0; j<m.cols(); ++j)
>  {
>    // do something fancy with m(i,j) that you cannot easily do using only
> Eigen expression
>  }
> }
>
> foo(a*b);
>
> Here the proper version of foo() should first copy mat to its respective
> nested type:
>
> typename T::Nested mat_nested(mat);
>
>
> Said that, finally I'm fine with both options.

Hm your example discouraged me a bit! I'm hesitating too. A good
compile-time error should be good enough.

Benoit