-
Notifications
You must be signed in to change notification settings - Fork 11
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
Add DiffResult for MArray #18
Conversation
You can also extend this to |
Updated. |
bump |
bump # 2 |
bump # 3 |
What would you think about #28 instead? |
I’m not sure I have strong opinions. This PR seems a bit simpler. Not sure what to do to get attention to this PR… frankly, I don’t even remember what this was for…. |
Okay @devmotion told me why #28 was a bad idea, so I think this PR is better, and I have the rights to merge it, I just have a few comments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes ensure that we don't mess up when value and derivs are of different types. What do you think?
Just gonna add some tests and we should be good to go |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #18 +/- ##
=======================================
Coverage 86.84% 86.84%
=======================================
Files 1 1
Lines 76 76
=======================================
Hits 66 66
Misses 10 10 ☔ View full report in Codecov by Sentry. |
@@ -36,7 +36,7 @@ Return `r::DiffResult`, with output value storage provided by `value` and output | |||
storage provided by `derivs`. | |||
|
|||
In reality, `DiffResult` is an abstract supertype of two concrete types, `MutableDiffResult` | |||
and `ImmutableDiffResult`. If all `value`/`derivs` are all `Number`s or `StaticArray`s, | |||
and `ImmutableDiffResult`. If all `value`/`derivs` are all `Number`s or `StaticArrays.SArray`s, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That way, if there is even one mutable array in the mix (like MArray
), the whole thing becomes a MutableDiffResult
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's wrong though, isn't it? All value
and derivs
have to be mutable, otherwise the MutableDiffResult
will error when trying to update the immutable component.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're right, so it's the other way around
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If any of the `value`/`derivs` is a `Number` or `StaticArrays.SArray`,
then `r` will be immutable. Otherwise, `r` will be mutable.
that's what we want, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, to me it seems that's what we want for StaticArrays. The safest option would be to make the ImmutableDiffResult
the default DiffResult
type, but given the wide range of mutable arrays (without clear way to catch them all apart from - to some extent - ArrayInterface.ismutable
) I think it's much easier implementation-wise to only add special cases for StaticArrays. Even though this is also doomed to fail with wrapper types such as Diagonal
etc...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Theoretically, if everyone used the API correctly, making Immutable
the default would not be breaking. Unfortunately, as seen in #26, SciML and others are playing fast and loose with realiasing.
So from an ecosystem point of view, any transition Mutable
-> Immutable
has the potential to be breaking
Asking for a review from someone else because these changes could either be considered breaking or a bug fix. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be good to run downdtream tests with ReverseDiff, ForwardDiff, etc to avoid accidentally breaking them.
Oh, the PR was already merged? I think generally we should require approval from people with write permissions (ie JuliaDiff members?). |
Sorry, I'll undo it. How do you suggest we run those downstream tests though, add FD and RD as test deps? |
See #35 for v2 |
This PR adds
Fixes NLsolve.jl's 254.
MArray
s are mutable, so I think this needs to be defined differently thanSArray
sBefore this PR:
After this PR: