Allow gradients in fmap #1
Conversation
|
Any chance of some documentation alongside this PR explaining what the purpose of the two-argument version of Additionally, why do we need a separate |
|
Its to make Optimisers.jl work by returning a slightly trained version of the model. The tuple function is so that we return a tuple of layers in a chain. I should revisit to see if its necessary still but otherwise this should be merged so we can release Optimisers.jl |
|
I agree that this should probably go in, but a comment of some kind explaining what you've said above would be great. |
|
bump! |
|
Woops, meant to say LGTM once the tests land. |
|
Allows writing something like Functors.fmap(x, y) do x, y
isnothing(x) && return y
isnothing(y) && return x
f(x,y)
endwhere x and y are basically NamedTuples out of Zygote, or a mix of the actual object tree (think Chain, model struct etc) and the corresponding gradients. |
| @@ -44,10 +44,29 @@ Equivalent to `functor(x)[1]`. | |||
| """ | |||
| children(x) = functor(x)[1] | |||
|
|
|||
| function functor_tuple(f, x::Tuple, dx::Tuple) | |||
There was a problem hiding this comment.
I don't think x is a tuple
| function functor_tuple(f, x::Tuple, dx::Tuple) | |
| function functor_tuple(f, x, dx::Tuple) |
| function _default_walk(f, x, dx) | ||
| func, re = functor(x) | ||
| map(func, dx) do x, x̄ | ||
| # functor_tuple(f, x, x̄) |
There was a problem hiding this comment.
This should work with the other change?
|
@DhairyaLGandhi this already has my approval, so feel free to merge any time :) |
No description provided.