New user self-registration is disabled due to spam. Please email eigen-core-team @ if you need an account.
Before reporting a bug, please make sure that your Eigen version is up-to-date!
Bug 1166 - MatrixXd block, VectorXd and noalias
Summary: MatrixXd block, VectorXd and noalias
Alias: None
Product: Eigen
Classification: Unclassified
Component: Core - expression templates (show other bugs)
Version: 3.3 (current stable)
Hardware: All All
: Normal Wrong Result
Assignee: Nobody
Depends on:
Reported: 2016-02-14 09:49 UTC by Benjamin Chretien
Modified: 2016-02-19 01:41 UTC (History)
3 users (show)

Repro code (885 bytes, text/x-c++src)
2016-02-14 09:49 UTC, Benjamin Chretien
no flags Details

Description Benjamin Chretien 2016-02-14 09:49:30 UTC
Created attachment 653 [details]
Repro code

While investigating an error in our code relying on Eigen, I noticed the following behavior. Given a MatrixXd a, the result of this operation on a block b of a MatrixXd m is wrong:

    b.noalias() = 2. * x.transpose() * a;

when noalias() is used and x is a VectorXd. As a result, the block b of the matrix contains the wrong data (misplaced in memory). However, if x is a MatrixXd with the proper size, things work normally. I attached a repro code that shows the issue. I tested in on Eigen 3.2.7 and 3.3-beta1.

    Eigen 3.2.92
    Using MatrixXd:
    With noalias():
     0  0
    30 44

    Without noalias():
     0  0
    30 44

    Using VectorXd:
    With noalias():
     0 44
    30  0

    Without noalias():
     0  0
    30 44

Am I doing something wrong here?
Comment 1 Gael Guennebaud 2016-02-14 22:02:14 UTC
I confirm. The problem is when extracting the inner-stride of the destination using:


which is not necessarily correct when the destination expression is not a vector expression at compile-time, as with m.block(1, 0, 1, 2). This works fine with m.row(1), which is the workaround you should follow.

On Eigen's side, a quick fix would be enforce the destination to be a vector by calling:


This should not produce any runtime overhead.
Comment 2 Benjamin Chretien 2016-02-15 01:02:22 UTC
Duly noted, thanks for the quick answer!
Comment 3 Gael Guennebaud 2016-02-15 20:46:14 UTC (3.2)
Summary:     Bug 1166: fix shortcomming in gemv when the destination is not a vector at compile-time.

btw, thanks for find that one.
Comment 4 Benjamin Chretien 2016-02-19 01:41:43 UTC
Well thanks for the quick fix (and maintenance release), it's greatly appreciated!

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