[BlockSparseArrays] Redesign block views again #1513
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is an iteration on the redesign of block views that was implemented in #1481, which implemented block views (i.e.
@view a[Block(1, 1)]
) as aSubArray
wrapping the block sparse array and storing the location of the desired block. It is also related to #1498, which introducedview!
/@view!
that may instantiate blocks if they don't exist.This PR defines a devoted type
BlockView
, and now@view a[Block(1, 1)]
either directly outputs the data of the block if it exists, or aBlockView
wrapping the block sparse array and the location of the desired block if the block doesn't exist.So for example:
I think this will make some operations with block views easier to implement, and also help to simplify some code internally.
I'm not totally settled on the design that views of existing blocks directly returns the block data, an alternative would be that it also outputs a
BlockView
which is more comparable to the current behavior that it outputs aSubArray
no matter what. However, I think it is worth trying out this design and seeing how it goes, it would be easy to change that later.@ogauthe this is related to our discussion in ITensor/BlockSparseArrays.jl#2. I think this new design will make it a bit easier to fix some issues with block views you brought up, like using them in
TensorAlgebra.contract
and inStrided.@strided
.