|Summary:||TriangularView<Derived, UnitLower>::coeff() does not return 1.0 for diagonal entries|
|Product:||Eigen||Reporter:||Jeff Trull <edaskel>|
|Component:||Core - general||Assignee:||Nobody <eigen.nobody>|
|Severity:||Documentation||CC:||chtz, gael.guennebaud, jacob.benoit.1|
|Version:||3.3 (current stable)|
Description Jeff Trull 2016-12-20 02:51:20 UTC
Created attachment 763 [details] code demonstrating that coeff() is not affected by the mode If you assign a TriangularView to a dense matrix, the diagonal entries are 1.0 as expected. However, if you use the coeff() method to access entries in the TriangularView, you get the underlying values, not the 0 (above the diagonal) or 1 (on the diagonal) values you would expect. The same appears to be true for UnitUpper.
Comment 1 Christoph Hertzberg 2016-12-20 15:19:24 UTC
This is expected behavior (having a branch in the coeff() would be too costly), and you should generally avoid low-level access to TriangularView (or SelfAdjointView). Admittedly, this should be documented! Actually, TriangularView::operator()(Index, Index) and SelfAdjointView::coeff(Index, Index) do check their input coordinates. Usually coeff() does no assertions, but should only be used when correct usage is guaranteed by the calling method.
Comment 2 Jeff Trull 2016-12-20 17:21:55 UTC
I am OK with calling this a documentation bug. As an outsider it would help to understand in what cases the "View" classes can be substituted for matrices. I naively assumed they would behave in all respects like the higher-level construct, while in fact that is only true for some uses, e.g., multiplication, assignment, etc.
Comment 3 Nobody 2019-12-04 16:38:57 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/1366.