I am calling out for a voting procedure starting today (April 12th, 2021) and lasting for two weeks on the adjoint ODE design doc which you can find here. This means that the voting period ends on Monday April the 26th 2021. The final result will then be available on April 27th. Please vote for
reject the design PR in its current form
accept the design PR as is
I would appreciate any rationale for rejecting should you vote for that option. This would help to improve the document for a second run.
I am tagging anyone coming to my mind who have known ODE background or have been involved in some way in this PR so far.
Also tagging @martinmodrak who suggested voting. As I understood we usually go for an “alert” period for a vote for an entire week first… given that I have been calling out for feedback many times on the PR, I am jump-starting this process somewhat. In addition we had a full month during May for an experimental phase of the feature during which I called for feedback on the prototype. As such I think there has been plenty time and visibility of the topic.
I will cross-post this call for vote on discourse, but the process itself should only happen as comments on the PR.
Many thanks everyone!
The PR is accepted if a majority (>50%) of votes go for option 2. Please cast your vote by noting the numeric option 1 or 2 which you prefer. People having been part of this PR are eligible to vote or those reading into the doc and have solid knowledge/experience with ODEs in Stan.
I dunno how we’re doing the votes, but I’m in favor of this.
There is a use case (this scales better with parameters)
It seems like at least a couple people other than @wds15 were able to run this (see here)
There’s no new software dependencies, so if we ever want to deprecate this interface, we just plug in another ODE solver behind the scenes for compatibility
There’s a bunch of work to systemetize the ODE tests here, so if this thing can fit into that testing framework then I am less worried about maintenance (it’ll be going through the same basic tests as all the other solvers + whatever specialized one it needs)
Much want to invest on digging deeper into the intricacies myself, I believe crowdsourcing it to capable users is the right thing to do. As to the tension point on specifying solver controls I have some thoughts on alternative approaches but they belong to another thread.
The prototype has been plugged into the ODE testing framework and it does play nicely with it. However, since there are more controls for the adjoint thing, I will do some adjoint specific tests in addition to the tests done by the framework.
@yizhang At this point it would be great if you could vote, yes. The exposed signature aims to maximize the control given to users and the hope is that we can provide a simpler user interface at a later point once more knowledge & experience has been gained with the function.
(the timing of the vote will allow for inclusion into the next release if accepted)