New user self-registration is disabled due to spam. Please email eigen-core-team @ lists.tuxfamily.org if you need an account.
Before reporting a bug, please make sure that your Eigen version is up-to-date!
Bug 536 - Lazy evaluation handles transpose expression wrong
Summary: Lazy evaluation handles transpose expression wrong
Status: NEW
Alias: None
Product: Eigen
Classification: Unclassified
Component: Core - general (show other bugs)
Version: 3.1
Hardware: All Linux
: Normal enhancement
Assignee: Nobody
URL:
Whiteboard:
Keywords:
Depends on: ExprEval
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-06 10:11 UTC by Magnus Lindhé
Modified: 2013-02-18 14:07 UTC (History)
4 users (show)



Attachments

Description Magnus Lindhé 2012-12-06 10:11:11 UTC
The lazy evaluation makes an expression of the type A = A.transpose() + A evaluate to the wrong result. Sometimes the built-in checks in Eigen misses this. A simplified code example (compiled with gcc 4.6.1):

Eigen::Matrix<float,2,2> A,B;
A << 1, 2, 3, 4;
B=A;
//A = A.transpose() + A; // Causes a failed assertion in Eigen
A = A.transpose() + A + A; // Runs, but gives wrong result
B = B.transpose().eval() + B + B; // Correct

The result is A=3, 12, 8, 12 (wrong) and B=3, 7, 8, 12 (correct). When I run the commented line, I get a failed assertion, with the help text "aliasing detected during tranposition, use transposeInPlace() " "or evaluate the rhs into a temporary using .eval()", but when I add an extra term, it seems that Eigen doesn't detect the problem.
Comment 1 Christoph Hertzberg 2012-12-17 17:42:35 UTC
I guess detecting this would require a much more complex check than at the moment. Basically, as soon as the assignment is performed it is required to check if A appears transposed() anywhere in the expression (actually, one could check at the same time if it appears in a product or in overlapping block-expressions).

Maybe the expression evaluator will solve this one day ...
Comment 2 Gael Guennebaud 2012-12-17 23:41:42 UTC
The goal of this aliasing detection mechanism was only to detect most common use cases, and we never claimed it was thorough.  Detecting all nested transposed matrices would not be very complicated to implement, but 1) this would increase compilation time quite a lot, and 2) there exist many other aliasing situations that are much more complicated to detect (think about sub matrices or permuted sub matrices...).

Overall, I'm tempted to say "wont fix".
Comment 3 Christoph Hertzberg 2012-12-19 13:49:43 UTC
I agree that its almost impossible to detect all kinds of aliasing. I'd still think that an advanced alias-checker could be nice sometimes (maybe only enabled by a compile flag). But that would definitely be low priority. 
Maybe we can postpone the decision until the expression evaluator is more or less stable and see how complicate it will be to integrate?

Note You need to log in before you can comment on or make changes to this bug.