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

[Jitse Niesen <jitseniesen@xxxxxxxxx>]

Dear all,

Some initial reactions on the open questions on the wiki page:
http://eigen.tuxfamily.org/index.php?title=Working_notes_-_Expression_evaluator

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 
expr.data() be defined for all expression objects and have it call 
evaluator.data() 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: