| 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> | ||||
| Status: | NEW --- | ||||||
| Severity: | Documentation | CC: | chtz, gael.guennebaud, jacob.benoit.1 | ||||
| Priority: | Normal | ||||||
| Version: | 3.3 (current stable) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
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. 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. -- 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. |
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.