You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It means it is more efficient to slice or work on the matrix column-by-column rather than row-by row. That is, the value of it would be in SparseColumnMajor <: AbstractColumnMajor.
BTW - as long as I'm wishing - how about supporting ReadOnlyArrays? Right now they are all reported as UnknownLayout regardless of the internal representation.
My use case is very focused on the question of the efficient access pattern for a matrix, that is, whether it is row-major, column-major, or neither. Since I do a lot of specific processing operations on my not-small matrices (sometimes, memory mapped), if they aren't in the "efficient" layout I re-layout them into a more efficient layout and only then start the processing (this isn't linear algebra, it is more of a "data frame" type of processing - statistics on each row or column, downsampling, slicing, etc.). I do have to pay the cost of doing the physical re-layouting once, and doubles the memory/disk usage, but this pays for itself very quickly when doing multiple such operations.
Speaking of which, is there an official way today to create an identical matrix to a given one, but with the opposite layout? E.g. convert a SparseMatrixCSC (column-major) to a Transpose{SparseMatrixCSC} (row-major) with the exact same size and content?
Any chance of seeing
SparseRowMajor
andSparseColumnMajor
layout support?The text was updated successfully, but these errors were encountered: