split dual AD and mathematical types

[mlubin]

There seems to be some conflict over whether we should follow the mathematical convention for dual numbers or use the definitions that allow dual numbers to be dropped in automatically to compute derivatives. I propose separating these into two separate types to settle the conflict.

As the primary use of DualNumbers, as far as I'm aware, is for computing derivatives, I'd argue that the AD type should keep the name Dual. This also avoids breakage downstream. Perhaps DualAlg could be used for the algebraic/mathematical type?

@Scidom @andreasnoackjensen

[papamarkou]

It's ok @mlubin, there is no actual conflict, at least not on my part. I think we both agree that the mathematically correct definition of dual equality differs from the one that serves the practical purposes of autodiff. We also both agree that the latter is what is used in practice. For this reason, as I have previously mentioned, I don't mind if we change the existing mathematical definition of equality to match that of autodiff. By that I mean that you can simply change the definition without needing to proceed and define a second type to satisfy mathematical equality. If for any reason mathametical equality arises in the future as a programming need, then we can create the second type - for now simply change the definition of == to save yourself from extra unnecessary work.

[andreasnoack]

I also don't think that it is worth spending time on a DualAlg type. The purpose for this package is to allow automatic differentiation so I think it is fine just to use the special definitions here. It would be nice to keep a note about that in the documentation though.