-
Notifications
You must be signed in to change notification settings - Fork 76
Extend Base.gradient instead of defining a new one on 0.4 #66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
|
I C. So it's the recently introduced handling of conflict export that breaks this, rather than the conflicting names themselves...... |
|
Appears so |
|
Updated |
Extend Base.gradient instead of defining a new one on 0.4
… use assertions to circumvent passing in Dim to ensure type stability
|
I don't think this was the right solution. There's more than one method to compute the gradient of a function. I don't think the Calculus version should be any special and take over the |
|
I agree. @mlubin: What do you think of trying to pull this package apart into separate packages for finite differentiation and symbolic differentiation? Now that ForwardDiff is out, I feel like I could take the work I did long ago on Calculus2 and try to adopt your API. We could then start to deprecate this package. |
|
Splitting into FiniteDiff and SymbolicDiff seems like a good idea. Both
|
|
No, the integration functionality is far inferior to what's in Base. |
I like this idea.
That would be great. I stumbled upon Calculus2 a while ago and was hoping the effort would be revived soon! Let me know how I can help, and feel free to file issues in ForwardDiff.jl if anything needs to change API-wise there to make things work out. |
Not sure if this is the best long term solution but at least it makes all tests pass and IMHO produce the least breakage for users.