![]() |
Just as rows provide a view on a specific row of a matrix, columns provide views on a specific column of a dense or sparse matrix. As such, columns act as a reference to a specific column. This reference is valid an can be used in every way any other column vector can be used as long as the matrix containing the column is not resized or entirely destroyed. Changes made to the elements (e.g. modifying values, inserting or erasing elements) are immediately visible in the matrix and changes made via the matrix are immediately visible in the column.
The blaze::Column class template represents a reference to a specific column of a dense or sparse matrix primitive. It can be included via the header file
The type of the matrix is specified via template parameter:
MT
specifies the type of the matrix primitive. Column can be used with every matrix primitive, but does not work with any matrix expression type.
Similar to the setup of a row, a reference to a dense or sparse column can be created very conveniently via the column()
function. This reference can be treated as any other column vector, i.e. it can be assigned to, copied from, and be used in arithmetic operations. The column can either be used as an alias to grant write access to a specific column of a matrix primitive on the left-hand side of an assignment or to grant read-access to a specific column of a matrix primitive or expression on the right-hand side of an assignment. The following two examples demonstrate this for dense and sparse matrices:
The column()
function can be used on any dense or sparse matrix, including expressions, as illustrated by the source code example. However, columns cannot be instantiated for expression types, but only for matrix primitives, respectively, i.e. for matrix types that offer write access.
A column view can be used like any other column vector. For instance, the current number of elements can be obtained via the size()
function, the current capacity via the capacity()
function, and the number of non-zero elements via the nonZeros()
function. However, since columns are references to specific columns of a matrix, several operations are not possible on views, such as resizing and swapping. The following example shows this by means of a dense column view:
The elements of the column can be directly accessed with the subscript operator. The numbering of the column elements is
where N is the number of rows of the referenced matrix. Alternatively, the elements of a column can be traversed via iterators. Just as with vectors, in case of non-const columns, begin()
and end()
return an Iterator, which allows a manipulation of the non-zero value, in case of a constant column a ConstIterator is returned:
Inserting/accessing elements in a sparse column can be done by several alternative functions. The following example demonstrates all options:
Both dense and sparse columns can be used in all arithmetic operations that any other dense or sparse column vector can be used in. The following example gives an impression of the use of dense columns within arithmetic operations. All operations (addition, subtraction, multiplication, scaling, ...) can be performed on all possible combinations of dense and sparse columns with fitting element types:
Especially noteworthy is that column views can be created for both row-major and column-major matrices. Whereas the interface of a row-major matrix only allows to traverse a row directly and the interface of a column-major matrix only allows to traverse a column, via views it is possible to traverse a row of a column-major matrix or a column of a row-major matrix. For instance:
However, please note that creating a column view on a matrix stored in a row-major fashion can result in a considerable performance decrease in comparison to a view on a matrix with a fitting storage orientation. This is due to the non-contiguous storage of the matrix elements. Therefore care has to be taken in the choice of the most suitable storage order:
Although Blaze performs the resulting matrix/vector multiplication as efficiently as possible using a column-major storage order for matrix B would result in a more efficient evaluation.
Previous: Rows Next: Arithmetic Operations