Can we contextualize `parent_type`?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
Research direction
Start by reading the linked PR and the issue's discussion of parent(x), parent_type(x), and the proposed BufferStyle categories. Compare the stated examples—SubArray, Tridiagonal, and FillArrays—and determine whether a concrete trait or generic f(x) = f(parent(x)) design can be specified. Done means reaching a settled, implementable interface proposal.
Written by the indexing model from the issue text.
Description
When I made this PR to base some good points were brought up about what we knew about parent(x) compared to x. With a few exceptions (that we should probably clean up), we simply use parent_type as convenient syntax for communicating the type of the underlying data buffer/collection. An informal search through juliahub shows that a handful of packages define something very similar independent of this package, so it's clearly something that has utility already. I'd like to know if we could do better.
The biggest hangup here is how we succinctly describe what assumptions persists between x and parent(x). The only approachable idea I have is a method like is_lazy_wrapper when we can assume that the wrapper type changes nothing. However, that seems extremely limiting and questionably useful.
A more approachable aspect to this is describing the kind of type that is parent_type(x). For example, sub-typing something like BufferStyle with these subtypes:
WrappedBuffer: single wrapped buffer likeSubArray.MultiBuffer: multiple distinct buffers likeTridiagonalComputedBuffer: buffer is computed on the fly and isn't stored in memory (e.g., FillArrays).
However, creating traits for describing parent_type(x) isn't terribly useful until we have a generic approach for doing f(x) = f(parent(x)).
- Dominant language
- Julia
- Stars
- 14
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from JuliaArrays/StaticArrayInterface.jl
-
tagbot-manual
Difficulty 1/5 Under an hour Newbie friendliness 68/100
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
-
Storage Order Open
Difficulty 5/5 Over a week Newbie friendliness 25/100
JuliaArrays/StaticArrayInterface.jl#4 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 32/100
JuliaArrays/StaticArrayInterface.jl#3 · 10 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
JuliaArrays/StaticArrayInterface.jl#10 · 2 comments ·
All issues in JuliaArrays/StaticArrayInterface.jl
Similar issues
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
interpolate! from a Float32 LatitudeLongitudeGrid fails on Metal: Float64 division in find_λ_range Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
CliMA/Oceananigans.jl#6056 ·
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
JuliaPluto/PlutoPlotly.jl#72 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
epiforecasts/BVDOutbreakSize#811 ·