-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add findblockindex
support for AbstractArray
#345
base: master
Are you sure you want to change the base?
Conversation
findblockindex
support for AbstractBlockArray
findblockindex
support for AbstractArray
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #345 +/- ##
==========================================
- Coverage 96.25% 95.60% -0.65%
==========================================
Files 18 18
Lines 1628 1639 +11
==========================================
Hits 1567 1567
- Misses 61 72 +11 ☔ View full report in Codecov by Sentry. |
Seems good to me, but it'll be better to not use |
Do you have an alternative that concats tuples? |
Perhaps |
This PR actually exemplifies the point I was trying to make in #336. It leads to this inconsistency: julia> using BlockArrays
julia> a1 = BlockArrays._BlockedUnitRange(2, [3, 6])
2-blocked 5-element BlockedUnitRange{Vector{Int64}}:
2
3
─
4
5
6
julia> a2 = mortar([2:3, 4:6])
2-blocked 5-element BlockVector{Int64, Vector{UnitRange{Int64}}, Tuple{BlockedUnitRange{Vector{Int64}}}}:
2
3
─
4
5
6
julia> findblockindex(a1, 4)
Block(2)[1]
julia> findblockindex(a1, (4,))
Block(2)[2]
julia> findblockindex(a2, (4,))
Block(2)[2] i.e. it is not clear if |
Another proposal for a "spelling" of this kind of operation (converting from a cartesian index to a block index) would be #346. With that proposal, instead of using |
It's the name of |
If you agree with this idea then I'll add tests.