Comparison with DifferentiationInterface.jl about abstractdifferentiation.jl HOT 2 OPEN

Thanks for the summary. I will respond to each point below.

1. Regarding ADTypes.jl, AbstractDifferentiation.jl predates that package. But we can of course support their AD types with an extension if needed or vice versa.
2. The @primitive macro is a feature but it is not essential to use. You can use method implementation to define the behaviour for a new AD backend.
3. The fallback is no longer based on Jacobian.
4. Regarding the use of closures, their use may be reduced and improved in AD.jl. But we need specific examples where closures gave a sub-optimal performance or type stability issues. Also for most backends now, we encourage using the native implementation of each AD package for any exported AD.jl function. This means that closure fallbacks are only useful when the backend package doesn't provide an implementation for such a function. In this case, we can strive to improve the closure implementation. Specific issues and PRs are welcome.
5. Regarding being first order only, this is a strict limitation of DI.jl.
6. Regarding, having one vector in and one out, there is no reason why we need to support multiple inputs and multiple outputs in AD.jl if the backend package doesn't. We can start with a single input and single output version. In fact, the ForwardDiff extension assumes a single input and single output. Same response for the types.
7. Regarding caching and mutating functions, I am open to proposals. Perhaps the implementation in DI.jl can be used to design a caching and mutating API for AD.jl.
8. Regarding Enzyme support, if DI.jl can support Enzyme then I am open to contributing the features needed for that support back to AD.jl

from abstractdifferentiation.jl.

I just updated the comparison to include the new features we added these past few weeks (mutating functions, second order, testing and benchmarking utilities)

from abstractdifferentiation.jl.