This is a follow on to #1259 which tries to do a similar amount of clean-up to the backend code generation. Once again, we treat reduce_sum as a special case still, but the other variadic HOFs share the same structure except for two details, which differ per signature:
Where does the pstream argument go in the call to the higher order function, e.g. dae(f, ..., msgs, ...). This differs between each function and its _tol version.
Where does the pstream argument get passed to the f in the above call? For DAEs, this is 4, for ODEs 3, etc. Another way of saying this is how many non-variadic arguments does the function f get called with in C++.
By adding this tiny bit of backend-specific data to the variadic signature table added in #1259 the code generation gets much nicer and cares a lot less about the specifics of Stan_math_signatures. If someone wants to build a non-C++ backend, they can just ignore these or set them to 0 for new signatures.
Changes to the test output only occurred because this change means that the names of the functors generated changed slightly, now it is based on the number specified in bullet 2 above rather than the name, so _odefunctor_ becomes _vari_3_functor_
Submission Checklist
[x] Run unit tests
Documentation
[ ] If a user-facing facing change was made, the documentation PR is here:
[x] OR, no user-facing changes were made
Release notes
Replace this text with a short note on what will change if this pull request is merged. This will be included in the release notes.
This is a follow on to #1259 which tries to do a similar amount of clean-up to the backend code generation. Once again, we treat
reduce_sumas a special case still, but the other variadic HOFs share the same structure except for two details, which differ per signature:pstreamargument go in the call to the higher order function, e.g.dae(f, ..., msgs, ...). This differs between each function and its_tolversion.pstreamargument get passed to thefin the above call? For DAEs, this is 4, for ODEs 3, etc. Another way of saying this is how many non-variadic arguments does the functionfget called with in C++.By adding this tiny bit of backend-specific data to the variadic signature table added in #1259 the code generation gets much nicer and cares a lot less about the specifics of
Stan_math_signatures. If someone wants to build a non-C++ backend, they can just ignore these or set them to 0 for new signatures.Changes to the test output only occurred because this change means that the names of the functors generated changed slightly, now it is based on the number specified in bullet 2 above rather than the name, so
_odefunctor_becomes_vari_3_functor_Submission Checklist
Release notes
Replace this text with a short note on what will change if this pull request is merged. This will be included in the release notes.
Copyright and Licensing
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the BSD 3-clause license (https://opensource.org/licenses/BSD-3-Clause)