-
-
Notifications
You must be signed in to change notification settings - Fork 139
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
Stateful Controls #559
base: dev
Are you sure you want to change the base?
Stateful Controls #559
Conversation
I can see this is a draft, LMK when you want a review! Happy to take a look on specific points if you want direct feedback earlier. (Although FWIW I think it'd be cleanest if #484 is the next 'big' thing we merge, just to avoid us having too many 'big' things in flight at the same time.) |
I'm good with that, although I think that's in @andyElking's control ;) |
This is the v1 of the stateful control PR.
This PR introduces a suite of internally breaking changes which allow for stateful paths. To the non-advanced user, this will likely have no impact on the way they interact with diffrax. It should not impact ODE users at all. SDEs users may be impacted as they might want to try the new "UnsafeBrownianPath" (or as I am calling it "DirectBrownianPath" since it isn't really that unsafe any more), but this should just allow for faster code. I tried several approaches to this problem, but I think based on the conversations in other issues (e.g. #548), that this is at least someone an aligned vision.
Functionaly, this was just a lot of adding arguments to things to support an extra path_state variable. Hence the internal breaking changes. However, these breaking changes come with some decent motivation:
Currently, this PR is missing a few things though.