Open ChrisRackauckas opened 1 month ago
Unfortunately I don't think this is an error we can resolve here (depending on the type).
You can't update an immutable type so doing an in place update doesn't make sense
I would assume the behavior of make_zero!
on a function with no enclosed data would just be a no op.
It could have enclosed data though.
Eg make_zero!(2.9) or something
On Sun, Jul 21, 2024 at 9:40 PM Christopher Rackauckas < @.***> wrote:
I would assume the behavior of make_zero! on a function with no enclosed data would just be a no op.
— Reply to this email directly, view it on GitHub https://github.com/EnzymeAD/Enzyme.jl/issues/1661#issuecomment-2241887847, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJTUXGNAFUZF2MBLMODGULZNRPKLAVCNFSM6AAAAABLHLDQ3KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBRHA4DOOBUG4 . You are receiving this because you commented.Message ID: <EnzymeAD/Enzyme. @.***>
If the data cannot be mutated then it can safely be skipped though. The use case here is that make_zero(f)
is used to make the shadow function and then Duplicated(f,make_zero!(df))
is used to reset the caches each time for safety in the the shadow data. But if the caches cannot be mutated, then they don't need to be zero'd.
Makezero! Internally uses a routine that indeed only updates the mutable parts. Presently, however we define the semantics of make zero! To zero all differentiable data and err otherwise (as it does here). If you were to pass the df as a duplicated in here you would get the wrong answer if it wasn’t zero’s fully
Okay then we're missing a utility for generically handling functions correctly, since duplicated functions have this behavior where I want to set things to zero before reusing, unless the values are not writable (because of course that means the last pass hasn't changed them)
Example from https://github.com/SciML/SciMLSensitivity.jl/pull/1067:
Throws:
But I haven't been able to isolate it any more.