Skip to content
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 a type-stable unstack method with Val dims arg #150

Merged
merged 3 commits into from
Mar 30, 2023

Conversation

gabrevaya
Copy link
Contributor

Addressing #149.

@codecov-commenter
Copy link

codecov-commenter commented Mar 21, 2023

Codecov Report

Merging #150 (ef9523d) into main (c957026) will increase coverage by 0.05%.
The diff coverage is 100.00%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##             main     #150      +/-   ##
==========================================
+ Coverage   88.40%   88.46%   +0.05%     
==========================================
  Files          13       15       +2     
  Lines         595      598       +3     
==========================================
+ Hits          526      529       +3     
  Misses         69       69              
Impacted Files Coverage Δ
src/utils.jl 90.14% <100.00%> (+0.06%) ⬆️

... and 2 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@ToucheSir
Copy link
Contributor

Instead of forcing it to be a positional arg, you can do what Base does with typed_cat and call an internal function with dims as a positional arg from unstack(...; dims). Then it's possible to add dispatches to the former for Val and more.

@gabrevaya
Copy link
Contributor Author

gabrevaya commented Mar 22, 2023

I was trying to copy the idea from cat_t in Base, as you suggested (I didn't find any function called typed_cat, so I guess you meant this one). Although I managed to dispatch to a Val method, now the type is not being inferred correctly. I still don't fully understand the logic of this (it's the first time I'm using Val). This is what I have so far:

@inline unstack(xs...; dims) = _unstack(dims, xs...)
_unstack(dims, xs...) = _unstack_t(dims, Base.promote_eltypeof(xs...), xs...)
dims2unstack(::Val{dims}) where dims = dims2unstack(dims)
dims2unstack(dims::Integer) = dims

@inline function _unstack_t(dims, ::Type{T}, xs...) where {T}
    unstackdims = dims2unstack(dims)
    [copy(selectdim(xs..., unstackdims, i)) for i in 1:size(xs..., unstackdims)]
end

I'll continue trying to make this work tomorrow.

@ToucheSir
Copy link
Contributor

ToucheSir commented Mar 24, 2023

Given unstack only takes a single xs, you can probably eliminate most of the varargs and splats. Something like this:

@inline unstack(xs; dims) = _unstack(dims, xs)

@inline dims2unstack(::Val{dims}) where dims = dims2unstack(dims)
@inline dims2unstack(dims::Integer) = dims

@inline _unstack(dims, xs) = [copy(selectdim(xs, dims2unstack(dims), i)) for i in axes(xs, dims2unstack(dims))]

I don't think @inline is required on all functions, so maybe try selectively removing it. Calling dims2stack inside the array comprehension is very important though, because it lowers to a Generator call which shoves the body into a closure (thus breaking const prop of unstackdims).

@gabrevaya
Copy link
Contributor Author

The only check that that failed was on Julia nightly and doesn't seem to be related to the changes in this PR. Should I do anything else?

src/utils.jl Outdated Show resolved Hide resolved
Co-authored-by: Brian Chen <ToucheSir@users.noreply.github.com>
@gabrevaya
Copy link
Contributor Author

Thanks! I commited your suggestion for removing that @inline and I see that you approved the PR but it is still not merged. Do I have to do something else or another reviewer is needed?

@ToucheSir
Copy link
Contributor

Wait for one of the maintainers to have a break from or finish work? If you don't hear anything after 24-48 hours, that's a better time to bump.

@ToucheSir ToucheSir merged commit ddc9cc4 into JuliaML:main Mar 30, 2023
@gabrevaya
Copy link
Contributor Author

OK, I apologize; I didn't mean to rush or bother you. I just wasn't sure if there was anything else I needed to do on my end. I thank you very much for your assistance, and I'm truly sorry for any inconvenience.

@ToucheSir
Copy link
Contributor

No need to apologize. My point is that open source dev means that people are all over the world with all sorts of time commitments. Longer lead times and very async communication should be the default expectation.

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.

None yet

3 participants