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

@functor is confused about properties vs fields #46

Open
mcabbott opened this issue Nov 10, 2022 · 5 comments · Fixed by #48
Open

@functor is confused about properties vs fields #46

mcabbott opened this issue Nov 10, 2022 · 5 comments · Fixed by #48

Comments

@mcabbott
Copy link
Member

It was noticed in FluxML/Flux.jl#2107 that Functors.jl + ProtoStruct.jl doesn't work, as Functors uses fieldnames + getproperty, which is overloaded by ProtoStruct.jl.

https://github.com/FluxML/Functors.jl/blob/v0.3.0/src/functor.jl#L11-L16

This is a bug, Functors should use getfield to be consistent. (Possibly the code was written before getproperty existed?)

@mcabbott mcabbott added the bug Something isn't working label Nov 10, 2022
@mcabbott mcabbott reopened this Nov 16, 2022
@mcabbott mcabbott removed the bug Something isn't working label Nov 16, 2022
@ToucheSir
Copy link
Member

With the reversion of #48, I guess our second attempt would be to try to use all properties? It won't be type stable for most types that define custom getproperty overloads, but playing around with https://github.com/JuliaObjects/ConstructionBase.jl/blob/40800e17ef953c5cccaeef2d1d651346cacc5014/src/ConstructionBase.jl#L75-L78 suggests it should be for those which don't.

@mcabbott
Copy link
Member Author

So the problem in #48 is Tangent, which Optimisers.jl wants to access via getproperty. Not sure that's a great design but it won't change soon.

For Functors to use properties-not-fields everywhere, I think it would have to be functor(guide, target) rather than functor(::Type{Guide}, target). I haven't thought through what else this would change.

@darsnack
Copy link
Member

For Functors to use properties-not-fields everywhere, I think it would have to be functor(guide, target) rather than functor(::Type{Guide}, target). I haven't thought through what else this would change.

In my refactor with ConstructionBase, I tried making children and rebuilder (thing that returns re) the foundation instead of functor. In this situation you don't have access to target and guide together, so you need access to the guide itself to close over the leaf nodes.

@mcabbott
Copy link
Member Author

One barrier to properties-everywhere is that Zygote uses fields:

julia> using ProtoStructs, Zygote

julia> @proto struct Mine
         num::Float64
       end

julia> gradient(x -> x.num^2, Mine(3.0))[1]
(properties = (num = 6.0,),)

julia> propertynames(Mine(3.0))
(:num,)

@ToucheSir
Copy link
Member

And because we return plain NamedTuples instead of e.g. Tangents, we don't even know whether that was meant to be a ProtoStruct. Even ChainRules assumes fields are being used in a few places—canonicalize comes to mind.

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 a pull request may close this issue.

3 participants