-
Notifications
You must be signed in to change notification settings - Fork 89
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
use ProjectTo functor everywhere, and update to v1 of CRC and CRTU #459
Conversation
I have made changes that make the following all work for me locally using ChainRulesCore, ChainRules, Test
@inferred(
rrule(hvcat, 1, rand(3)', transpose(rand(3)))[2](rand(2,3))
)
using ChainRulesTestUtils
test_rrule(hvcat, 1, rand(3)', transpose(rand(3)) ⊢ rand(1,3)) |
One way you could avoid boilerplate here is to define a macro which turns
into
In fact even without a macro, a
|
still failing: it seems that solving julia> @inferred ProjectTo(rand(3, 3))(Diagonal(rand(3)))
ERROR: return type Diagonal{Float64, Vector{Float64}} does not match inferred return type Union{Base.ReshapedArray{Float64, 2, Diagonal{Float64, Vector{Float64}}, Tuple{Base.MultiplicativeInverses.SignedMultiplicativeInverse{Int64}}}, Diagonal{Float64, Vector{Float64}}} could solve some (maybe all?) of the inference issues |
For the inference problems, I am happy enough to open an issue and come back to them.
Can we insert a |
@thunk(project_y(reshape(x .* ΔΩ, axes(y)))), | ||
) | ||
return (NoTangent(), xthunk, ythunk) | ||
x̄ = @thunk(project_x(reshape(y .* ΔΩ', axes(x)))) |
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.
Is this permanent or until we have something like JuliaDiff/ChainRulesCore.jl#393?
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.
Yeah,
more generally I hate the InplacableThunks that are just deferring broadcast materialization.
They are so boilerplatey.
That has its own issue JuliaDiff/ChainRulesCore.jl#274
and is probably going to be easier to solve.
I am more than happy to delete them.
Can always add them back
This is the partner to JuliaDiff/ChainRulesCore.jl#385
it matches against #457
It is much cleaner and it should be good again inference problems from closing over types,
as the type gets put into a type-parameter of
project_A
andproject_B
Following minimized version works find for me, haven't tested real thing properly.