DiffBase + Package Organization?

[jrevels]

We'll soon have enough packages sharing code that it makes sense to re-examine how we're organizing JuliaDiff. I have two proposals which I won't have time to work on for at least a month, but I'll write them up now to allow time for discussion.

cc @mlubin @johnmyleswhite @KristofferC @dpsanders

1. DiffBase.jl

This package could define a common differentiation interface for other packages to implement, but probably not overload (since it could result in ambiguities/conflicts between packages). The interface should still allow other packages to use implementation-specific optional/keyword arguments.

It could also implement DiffResult types - essentially the ForwardDiffResult types currently in ForwardDiff.jl, perhaps with some tweaks.

Finally, this package could contain an automated test and benchmark suite of various differentiable functions written against the API DIffBase provides.

2. Replace DualNumbers.Dual with ForwardDiff.Dual

I'd like to decouple ForwardDiff's dual number implementation from the rest of ForwardDiff, since the multidimensional dual numbers are useful as a standalone tool (e.g. for my upcoming reverse-mode package). Last time I checked, ForwardDiff.Dual provides all the functionality (and more) of DualNumbers.Dual without any performance loss. Would anybody be opposed to a straight replacement of the implementation in DualNumbers.jl?

AFAIK, ForwardDiff.Dual also constitutes a more general hyper-dual number implementation than HyperDualNumbers.Hyper, but I'm not sure of the performance difference.

[dpsanders]

cc @lbenet

[jrevels]

Another area that could be covered by DiffBase might be an API for selecting specific partial derivatives of the input (e.g. via a list of indices, or maybe a view). This would be useful for exploiting Jacobians/Hessians sparsity patterns.

[jrevels]

DiffBase now exists, and the DualNumbers replacement discussion is now here: JuliaDiff/DualNumbers.jl#45.