Re: [eigen] news on the refactoring of the expression template mechanism

[ Thread Index | Date Index | More Archives ]

Dear all,

Some initial reactions on the open questions on the wiki page:

This is more technical, so I put it in a separate message.

What about DirectAccessBit?

Currently it is still handled by the expressions because DenseCoeffBase
need it to enable data/outerStride/innerStride and the likes. However,
it not clear that the propagation of DirectAccess is generic and it
seems to rather be an evaluation details.

Yes, it is more naturally part of evaluators. One possibility is to have be defined for all expression objects and have it call giving a compile-time error if the expression is not direct access and the evaluator objects does not have a .data() method. This will not give a very nice compile-time error though so the other possibility is to have the expression object depend on DirectAccessBit as defined in the evaluator flag in order to enable .data(). This introduces a dependency, but that seems to me not too bad.

What to do with TriangularView::solve<OnTheRight>(lhs)?

We want to deprecate this API and use lhs * tri.inverse().

So TriangularView::solve<OnTheRight> could return a
Product<Lhs,Inverse<TriangularView>> instead of a Solve<> expression for
the "OnTheLeft" case.

I feel a bit uncomfortable telling people to write inverse to solve because I (and others) teach people not to use inverse. Of course I know (or at least hope!) that Eigen does not actually compute the inverse but that may be a subtlety lost on some.

On the other hand, solve on the right is not a very clear terminology; I still do not know immediately what's on the left and what's on the right.

Clarify StorageKind versus XprShape

I am a bit lost here with the terminology. My understanding is the following:

Mail converted by MHonArc 2.6.19+