Skip to content
Snippets Groups Projects

Export missing functionality in MatrixIndexSet

Merged Carsten Gräser requested to merge feature/export-matrixindexset-data into master
1 unresolved thread

The MatrixIndexSet class provides access to an incomplete subset of its internal data. While the number of rows is exported, the number of cols and the column indices per row have been missing so far. This was an oversight, since one can hardly use the class without this, unless one relies on the dedicated exportIdx() method for BCRSMatrix.

With the missing data exported, one can now easily use MatrixIndexSet to build patterns for other sparse matrix classes.

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
143 143 size_type rows() const {return rows_;}
144 144
145 /** \brief Return the number of columns */
146 size_type cols() const {return cols_;}
147
148 /**
149 * \brief Return column indices of entries in given row
150 *
151 * This returns a range of all column indices
152 * that have been added for the given column.
153 * Since there are different internal implementations
154 * of this range, the result is stored in a std::variant<...>
155 * which has to be accessed using `std::visit`.
156 */
157 const auto& columnIndices(size_type row) const {
158 return indices_[row];
  • Isn't this exposing an implementation detail? Or should the FlatSet be public? I came across this while modifying this class in a backwards compatible manner.

  • IMO there's no reason to make FlatSet public, because you don't need to know the type. The documentation tells you all you need to know: You get a const reference to an std:variant<...> storing a range of unspecified type. Hence you should use

    std::visit([&](const auto& columnIndex) {
    ...
    }, matrixIndexSet.columnIndices(row));
  • Please register or sign in to reply
  • Santiago Ospina De Los Ríos mentioned in merge request !607

    mentioned in merge request !607

  • Please register or sign in to reply
    Loading