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 would be nice to have a more convenient/compact syntax for merging adjacent blocks. Right now you can do that by indexing with new axes that have a new blocking structure (see the related discussion #347), but that requires a lot of work to be done "by hand" by the user to determine the new block sizes.
From what I can tell, the best way to do this right now is:
(which doesn't work right now). Writing out BlockVector(Block.(1:4), [2, 2]) is a bit annoying, but the idea is that it expresses the intent better: the user doesn't have to deal with any of the block lengths themselves, they just express which blocks should get merged together. This is analogous to the block version of indexing with blockedrange([2, 2]) in order to define a new blocking structure. Perhaps it even warrants a devoted syntax like blockedblockrange([2, 2]) for constructing BlockVector(Block.(1:4), [2, 2]) (or a devoted type BlockedBlockRange).
Related to #184, one could imagine generalizing this to something like BlockVector([Block(1), Block(3), Block(2), Block(4)], [2, 2]), which would be a fused operation for permuting blocks along an axis and then merging adjacent blocks. We would have many applications for that kind of operation.
The text was updated successfully, but these errors were encountered:
It would be nice to have a more convenient/compact syntax for merging adjacent blocks. Right now you can do that by indexing with new axes that have a new blocking structure (see the related discussion #347), but that requires a lot of work to be done "by hand" by the user to determine the new block sizes.
From what I can tell, the best way to do this right now is:
as discussed in #347. A proposal for a more convenient syntax would be:
(which doesn't work right now). Writing out
BlockVector(Block.(1:4), [2, 2])
is a bit annoying, but the idea is that it expresses the intent better: the user doesn't have to deal with any of the block lengths themselves, they just express which blocks should get merged together. This is analogous to the block version of indexing withblockedrange([2, 2])
in order to define a new blocking structure. Perhaps it even warrants a devoted syntax likeblockedblockrange([2, 2])
for constructingBlockVector(Block.(1:4), [2, 2])
(or a devoted typeBlockedBlockRange
).Related to #184, one could imagine generalizing this to something like
BlockVector([Block(1), Block(3), Block(2), Block(4)], [2, 2])
, which would be a fused operation for permuting blocks along an axis and then merging adjacent blocks. We would have many applications for that kind of operation.The text was updated successfully, but these errors were encountered: