DualNumbers.jl icon indicating copy to clipboard operation
DualNumbers.jl copied to clipboard

Transfer DualNumbers implementation from ForwardDiff

Open ranjanan opened this issue 8 years ago • 6 comments

Well, I looked at https://github.com/JuliaDiff/DualNumbers.jl/issues/45, so I thought this PR might help. The code is basically the same, but I exported Dual, value and partials. I also added pretty printing, so Dual Numbers would look like:

julia> d = Dual(4, 1, 3)
4 + 1ϵ₁ + 3ϵ₂

ranjanan avatar Feb 13 '17 16:02 ranjanan

I think we should definitely try to keep the git history for these files.

KristofferC avatar Feb 13 '17 16:02 KristofferC

Thanks @ranjanan. Before you go down this route, be warned that it will probably involve a good bit of work and digging into the implementation details of both packages. I had planned on doing this work myself after v0.6 released to avoid having to continuously update with breakage/depwarn fixes.

We need the change-over to not merely swap out the old implementation for ForwardDiff's, but to ensure that the feature sets of the two implementations are appropriately merged. We'll wish to drop some of the old behaviors, while other behaviors we'll wish to preserve, probably requiring new definitions. For example, there are some primitives defined on DualNumbers.Dual that are not yet defined on ForwardDiff.Dual. There might be more subtle behavioral changes as well.

Things that have to be done (besides just porting over the code):

  • [ ] Implement a deprecation layer
  • [ ] Implement whatever new functionality we need to appropriately merge the behavior of the two implementations
  • [ ] Write new tests for any new definitions
  • [ ] Write documentation describing the new interface

I'd also like my name added to the LICENSE (and I believe @mlubin is also within his rights to request this, but I'll let him speak for himself). I believe doing this requires Theo's permission?

Some comments on this PR as it is:

  • I'm not sure we want to export anything (especially such a generic function name like value), might be better to let users import these themselves. But I'm usually more conservative in this area ever since dealing with the whole Base.gradient confusion 😛
  • As somebody working with Duals quite a lot, I strongly prefer ForwardDiff's current pretty printing. See my comment here.

jrevels avatar Feb 13 '17 17:02 jrevels

@jrevels Thank you for your comments. I shall work to complete those objectives. I'd be most grateful if you would comment as and when you see something worth discussing, such as an API that's being deprecated, etc.

ranjanan avatar Feb 14 '17 17:02 ranjanan

Seems to be failing because of https://github.com/travis-ci/travis-ci/issues/4942, adding the following fix (https://github.com/travis-ci/travis-ci/issues/4942#issuecomment-159132444) to .travis.yml

ranjanan avatar Feb 21 '17 04:02 ranjanan

This fails because the function erf has been moved to SpecialFunctions.jl on v0.6

ranjanan avatar Feb 21 '17 05:02 ranjanan

What is the status of this PR? Is this just waiting for resolving the conflicts?

hyrodium avatar Apr 17 '22 05:04 hyrodium