Our higher-order function optimizations don't work if the passed-in function closes over TraceReals about reversediff.jl HOT 3 CLOSED

So after thinking about this for a bit (I actually discovered it yesterday), and drawing on a little bit of experience from JuliaDiff/ForwardDiff.jl#83, I think the safest and most tenable approach is to simply not apply the unsafe optimizations by default, and instead provide users an @optdiff macro (or something) which can be used to assert that it is safe to perform an AD optimization based on context.

Note that it really would have to be an unchecked user-assertion; I don't think you can adequately check for function purity at macro-time (well, maybe you could, but it would probably be really messy/fragile). If Julia ever gets better support for introspecting function purity (an ispure trait or something), we might enable the optimization for pure functions automatically.

Anyway, requiring a directive isn't the most elegant solution, but it would at least solve the problem and still allow users to access the optimization.

from reversediff.jl.

What are the unsafe optimizations?

from reversediff.jl.

What are the unsafe optimizations?

See here.

We overload map/broadcast for AbstractArray{T <: TraceReal} so that we can skip writing a bunch of nodes to the tape. Instead, we get the derivatives in the forward pass using arrays of Duals, and store the whole map/broadcast operation as a single "bulk" node (whose reverse pass behavior is defined here).

This optimization is unsafe if the function passed to map/broadcast closes over TraceReals, because those TraceReals will then unexpectedly write operations to the tape, where the optimization assumes that it's skipping though operations.

Unfortunately, like perturbation confusion, it's probably not transparent for a user to predict when this kind of thing will happen. It's also hard to detect automatically, so we can't reliably warn users either.

from reversediff.jl.