Comments (7)
@ToucheSir any news on this issue?
from zygote.jl.
It's possible that either TaylorDiff.jl or Julia Base changed some implementation details between 1.9 and 1.10, so that code used to take a path that was differentiable but now is not.
Can confirm it goes even deeper than this to the compiler. To demonstrate:
1.9:
julia> @code_warntype TaylorScalar((1,))
MethodInstance for TaylorScalar(::Tuple{Int64})
from TaylorScalar(value::Tuple{Vararg{T, N}}) where {T, N} @ TaylorDiff ~/.julia/packages/TaylorDiff/SMDgC/src/scalar.jl:17
Static Parameters
T = Int64
N = 1
Arguments
#self#::Type{TaylorScalar}
value::Tuple{Int64}
Body::TaylorScalar{Int64, 1}
1 ─ %1 = Core.apply_type(TaylorDiff.TaylorScalar, $(Expr(:static_parameter, 1)), $(Expr(:static_parameter, 2)))::Core.Const(TaylorScalar{Int64, 1})
│ %2 = (%1)(value)::TaylorScalar{Int64, 1}
└── return %2
1.10:
julia> @code_warntype TaylorScalar((1,))
MethodInstance for TaylorScalar(::Tuple{Int64})
from TaylorScalar(value::Tuple{Vararg{T, N}}) where {T, N} @ TaylorDiff ~/.julia/packages/TaylorDiff/SMDgC/src/scalar.jl:17
Static Parameters
T = Int64
N = 1
Arguments
#self#::Type{TaylorScalar}
value::Tuple{Int64}
Body::TaylorScalar{Int64, 1}
1 ─ %1 = Core.apply_type(TaylorDiff.TaylorScalar, $(Expr(:static_parameter, 1)), $(Expr(:static_parameter, 2)))::Core.Const(TaylorScalar{Int64, 1})
│ %2 = %new(%1, value)::TaylorScalar{Int64, 1}
└── return %2
Essentially, the compiler can skip the intermediate step of calling the Type constructor when constructing new values. This means that rules like https://github.com/JuliaDiff/TaylorDiff.jl/blob/4f7b477b188ef15f6a4368285bb2c40319089a48/src/chainrules.jl#L9-L12 may not be picked up because Zygote has a fallback path for Expr(:new)
it uses unconditionally. Evidently something needs to change to workaround this change in internals, but it's not clear who should make that change yet.
from zygote.jl.
Are you using TaylorDiff v0.2.1 (the latest released version) but looking at the code of the TaylorDiff.jl main branch? Note that there seem to have been a lot of changes between the two.
As for the behaviour being different between versions, I would not suspect rules not being picked up first. It's possible that either TaylorDiff.jl or Julia Base changed some implementation details between 1.9 and 1.10, so that code used to take a path that was differentiable but now is not. Again though, we need to know what versions of Zygote and TaylorDiff you're using, as well as if they're the same versions across 1.9 and 1.10.
from zygote.jl.
Thank you so much for your quick response. I was going to add the versions of the packages, and I completely forgot.
For both, 1.9.4
and 1.10+
I am using the latest versions of the packages.
[e88e6eb3] Zygote v0.6.69
[b36ab563] TaylorDiff v0.2.1
from zygote.jl.
Can you try adding TaylorDiff#main and seeing if that changes things?
from zygote.jl.
Just did it.
pkg> add TaylorDiff#main
Cloning git-repo `https://github.com/JuliaDiff/TaylorDiff.jl.git`
Updating git-repo `https://github.com/JuliaDiff/TaylorDiff.jl.git`
same error
from zygote.jl.
Unfortunately, no. I've not heard anything from the Base Julia side about possible solutions and I wouldn't know how to tackle this on the Zygote side. If somebody has news on the former or a concrete proposal for the latter, please chime in.
from zygote.jl.
Related Issues (20)
- `gradient` broken for `(*)(::Diagonal{Real}, ::Matrix{Complex}, ::Diagonal{Real})` when updating Julia 1.8 -> 1.9 HOT 6
- Method ambiguities reported by Aqua
- slow/high allocation gradient with mapreduce and iterators HOT 11
- error in summation of product iterator HOT 2
- `sort(x; rev=true)` is not supported HOT 1
- Incorrect gradients for `plan_rfft(x) * x` HOT 2
- Gradient of scalar function of gradient giving mutating array error HOT 4
- `sum` with CUDA and view on array errors HOT 3
- Cannot take gradient of sort on 2D CuArray HOT 1
- `Ref` and broadcasting issue HOT 1
- Strip zygote frames from mutation error stack trace HOT 1
- Few issues in the Zygote Home Page documentation HOT 1
- OOM when computing the gradient in an embarrassingly parallel problem HOT 1
- Pullback over jacobian HOT 6
- `withjacobian` flattens the output when it is a matrix HOT 1
- Gradient wrt to a sparse matrix is mathematically wrong HOT 6
- Increasing memory usage in each call of gradient HOT 1
- Precompilation error in Julia nightly HOT 1
- Gradient involving `LinearAlgebra.tr` errors HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zygote.jl.