-
-
Notifications
You must be signed in to change notification settings - Fork 16
add fcollect #13
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 fcollect #13
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like the two-arg version is because we don't have something like children(x) = functor(x)[1]
in Functors.jl. I would prefer syntax like:
a = fcollect(m; f = x -> all(isleaf, children(x)) ? x : nothing)
filter(!isnothing, a)
Co-authored-by: Kyle Daruwalla <daruwalla.k.public@icloud.com>
Yeah. I think we can remove the filter(x -> all(isleaf, children(x)), fcollect(m)) What do you say? |
Yeah I think that would match the name |
We'll want to settle on the same name for |
I'd go with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good to me. Will probably want @ToucheSir's review since he has more wisdom on Functor-y things than me.
|
I changed my mind, i think it is more convenient to specify what to exclude from the recursion instead of what to include, so removed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, this is essentially Flux.destructure
without trying to shove everything into one vector. One thing we could look at next is creating an iterable version. Then fcollect
could be expressed simply as collect(fiter(m, ...))
.
Does anyone have merge rights? |
I don't think so |
we good? |
Follow up to the discussion in FluxML/Flux.jl#1444.
I tried to give maximum flexibility to the interface.
Notice that it makes sense to pass a 2-args function
f(v, vs)
instead of a 1-argf(v)
, this is because applying a 1-argf
is quite simple a-posterioriPossible applications: