Foundations for Efficient and Expressive Differentiable Programming [pdf]
1–10 of 15 posts
Re: Foundations for Efficient and Expressive Differentiable Programming [pdf]
#2Re: Foundations for Efficient and Expressive Differentiable Programming [pdf]
#3Co-author here. Happy to answer any questions, as usual ...
"Demystifying Differentiable Programming: Shift/Reset the Penultimate Backpropagator" https://www.cs.purdue.edu/homes/rompf/papers/wang-preprint20...
The Lantern framework is available here: https://github.com/feiwang3311/Lantern
Re: Foundations for Efficient and Expressive Differentiable Programming [pdf]
#4Co-author here. Happy to answer any questions, as usual ...
What you call "delimited continuations" sounds a bit like how AD works in Julia's Flux package (and maybe elsewhere): During the forward calculation, a chain of functions is constructed, whose evaluation is the backward pass. This is done by overloading the original * to return both x * y and a closure Δ -> (Δ * y, x * Δ).
Does that sound right, are these indeed similar, or have I mis-understood something? I have never read Scala, but if I squint I can make your overloading of * is doing something similar.
Re: Foundations for Efficient and Expressive Differentiable Programming [pdf]
#5Co-author here. Happy to answer any questions, as usual ...
This looks interesting, thanks. What you call "delimited continuations" sounds a bit like how AD works in Julia's Flux package (and maybe elsewhere): During the forward calculation, a chain of functions is constructed, whose evaluation is the backward pass. This is done by overloading the original * to return both x * y and a closure Δ -> (Δ * y, x * Δ). Does that sound right, are these indeed similar, or have I mis-…
Re: Foundations for Efficient and Expressive Differentiable Programming [pdf]
#6Co-author here. Happy to answer any questions, as usual ...
Like all really good ideas, this one seems "obvious" in hindsight. I mean that is a compliment: It would have never occurred to me that transforming code into continuation-passing-style code would allow for automatic differentiation through all dynamic control-flow structures, by leveraging the function-call stack, thus eliminating the need for some kind of "tape" data structure, e.g., as in PyTorch.
My question is about the ongoing work to provide a JIT compiler for Python code. Do you expect it will provide full support for the entire PyTorch and/or Tensorflow APIs?
Re: Foundations for Efficient and Expressive Differentiable Programming [pdf]
#7Earlier quoted context omitted.
This looks interesting, thanks. What you call "delimited continuations" sounds a bit like how AD works in Julia's Flux package (and maybe elsewhere): During the forward calculation, a chain of functions is constructed, whose evaluation is the backward pass. This is done by overloading the original * to return both x * y and a closure Δ -> (Δ * y, x * Δ). Does that sound right, are these indeed similar, or have I mis-…
It's different -- instead of returning a closure, we take a closure as additional parameter (check paper for details). This means that the call stack stays intact and all intermediate values can be stack-allocated.
(Note BTW that the github page has a dead link to the paper.)
Re: Foundations for Efficient and Expressive Differentiable Programming [pdf]
#8Co-author here. Happy to answer any questions, as usual ...
Very cool. Like all really good ideas, this one seems "obvious" in hindsight. I mean that is a compliment: It would have never occurred to me that transforming code into continuation-passing-style code would allow for automatic differentiation through all dynamic control-flow structures, by leveraging the function-call stack, thus eliminating the need for some kind of "tape" data structure, e.g., as in PyTorch. My qu…
Lantern supports a good deal of PyTorch (via Snek, our Python front-end similar to AutoGraph) and can also read ONNX. Full feature parity is not our main goal--so far, supported features have been driven mostly by what is required for certain interesting models.
Re: Foundations for Efficient and Expressive Differentiable Programming [pdf]
#9Earlier quoted context omitted.
It's different -- instead of returning a closure, we take a closure as additional parameter (check paper for details). This means that the call stack stays intact and all intermediate values can be stack-allocated.
OK, thanks, sounds worth trying to wrap my head around... (Note BTW that the github page has a dead link to the paper.)
Re: Foundations for Efficient and Expressive Differentiable Programming [pdf]
#10Which shows how to connect forward and reverse mode auto differentiation in a very elegant way