Skip to content

Conversation

dlfivefifty
Copy link
Member

No description provided.

Copy link

codecov bot commented Feb 6, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.59%. Comparing base (4d386cf) to head (ac75028).
Report is 2 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #445      +/-   ##
==========================================
+ Coverage   93.55%   93.59%   +0.04%     
==========================================
  Files          18       18              
  Lines        1644     1656      +12     
==========================================
+ Hits         1538     1550      +12     
  Misses        106      106              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@mtfishman
Copy link
Collaborator

Looks like this closes #184? Thanks by the way, this will be really useful. Curious to hear your thoughts on #358, which is related.

@dlfivefifty dlfivefifty changed the title Support views involving vectors of blocks Support views involving vectors of blocks, Fixes #184 and #358 Feb 6, 2025
@dlfivefifty
Copy link
Member Author

OK I added a fix for #358 as well

@mtfishman
Copy link
Collaborator

OK I added a fix for #358 as well

Amazing, thanks!

@dlfivefifty dlfivefifty merged commit a4e544e into master Feb 6, 2025
16 checks passed
@dlfivefifty dlfivefifty deleted the dl/viewsofblockvector branch February 6, 2025 16:38
dlfivefifty pushed a commit that referenced this pull request Jul 1, 2025
This introduces a generalization of `BlockSlice` for views involving
vectors of `Block` and `BlockIndexRange`, building off of #445.

I call it `BlockedSlice` but I'm open to suggestions. At first I tried
to just generalize `BlockSlice` to be an `AbstractVector` subtype but
some operations depend on it being an `AbstractUnitRange` so I think it
makes sense to have both.

The motivation is that in
https://github.com/ITensor/BlockSparseArrays.jl it would be helpful to
preserve information about the original blocks being sliced when taking
views involving vectors of `Block` and `BlockIndexRange`. #445 drops the
blocks input in the slice operation, so it is hard to tell if a certain
slice operation was really originally blockwise.

@dlfivefifty curious to hear your thoughts on this since you wrote #445.
dlfivefifty added a commit that referenced this pull request Jul 10, 2025
Fixes #359.

This introduces syntax for merging blocks by indexing with nested
vectors of `Block{1}`, `BlockRange{1}`, `BlockIndexRange{1}`, etc. The
implementation is very similar to #445.

As an example:
```julia
julia> using BlockArrays

julia> A = BlockArray(randn(8, 8), [2, 2, 2, 2], [2, 2, 2, 2])
4×4-blocked 8×8 BlockMatrix{Float64}:
  0.163738   -0.859246  │  -0.399256  -0.143974   │  -0.812783   0.469877  │   0.0631785   1.56266  
 -0.209473    1.23701   │   0.479233   0.219572   │  -0.548844   1.363     │   0.795119   -0.169581 
 ───────────────────────┼─────────────────────────┼────────────────────────┼────────────────────────
  1.34493    -0.846004  │   1.32566    0.470043   │   0.650647   0.617614  │  -0.0926643   0.550304 
  1.20779    -0.528143  │   1.09621   -0.0868135  │  -0.178719  -0.105456  │   0.243687   -1.31676  
 ───────────────────────┼─────────────────────────┼────────────────────────┼────────────────────────
  1.201       1.48691   │   0.264342   0.696739   │  -0.86067   -0.608839  │  -0.082433   -0.0931981
  0.674171   -1.23494   │   0.124443   1.94983    │   0.929236  -1.62257   │  -0.693029   -0.0212493
 ───────────────────────┼─────────────────────────┼────────────────────────┼────────────────────────
  0.0174839   1.65394   │  -0.851706  -1.23722    │   1.63834    0.158663  │   1.27422    -2.37923  
  1.28377     0.364039  │   0.564611  -1.346      │  -0.619627   0.240933  │   0.270664   -0.593572 

julia> A[[[Block(1), Block(2)], [Block(3), Block(4)]], [[Block(1), Block(2)], [Block(3), Block(4)]]]
2×2-blocked 8×8 BlockedMatrix{Float64}:
  0.163738   -0.859246  -0.399256  -0.143974   │  -0.812783   0.469877   0.0631785   1.56266  
 -0.209473    1.23701    0.479233   0.219572   │  -0.548844   1.363      0.795119   -0.169581 
  1.34493    -0.846004   1.32566    0.470043   │   0.650647   0.617614  -0.0926643   0.550304 
  1.20779    -0.528143   1.09621   -0.0868135  │  -0.178719  -0.105456   0.243687   -1.31676  
 ──────────────────────────────────────────────┼──────────────────────────────────────────────
  1.201       1.48691    0.264342   0.696739   │  -0.86067   -0.608839  -0.082433   -0.0931981
  0.674171   -1.23494    0.124443   1.94983    │   0.929236  -1.62257   -0.693029   -0.0212493
  0.0174839   1.65394   -0.851706  -1.23722    │   1.63834    0.158663   1.27422    -2.37923  
  1.28377     0.364039   0.564611  -1.346      │  -0.619627   0.240933   0.270664   -0.593572 

julia> A[[[Block(1)[2:2], Block(2)[2:2]], [Block(3)[2:2], Block(4)[2:2]]], [[Block(1)[2:2], Block(2)[2:2]], [Block(3)[2:2], Block(4)[2:2]]]]
2×2-blocked 4×4 BlockedMatrix{Float64}:
  1.23701    0.219572   │   1.363     -0.169581 
 -0.528143  -0.0868135  │  -0.105456  -1.31676  
 ───────────────────────┼───────────────────────
 -1.23494    1.94983    │  -1.62257   -0.0212493
  0.364039  -1.346      │   0.240933  -0.593572 
```

It feels unfortunate that the implementation has to be done in this way
by catching the various cases manually with dispatch, but I can't think
a better way (besides introducing a custom slicing operation).

Co-authored-by: Sheehan Olver <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants