I am looking to add a new diffusion decision model (DDM) PDF to the Stan Math library. Currently in the Stan Math library, this PDF exists in its 4-parameter variant (wiener_lpdf
). I have followed the guidelines and have implemented the 5-parameter version (plus corresponding tests) in a forked version of the Stan Math library based on the existing code (wiener_lpdf
).
Now, I would like to test this version while actually fitting data (and not only when compiling the Stan Math library directly at the shell). Is there a way to use any of the Stan interfaces such as CmdStan
or CmdStanR
with a new addition to the Stan Math library? I have not found any corresponding documentation and my attempts were not fruitful.
A section in the guidelines suggest adding code to expose new functions in a specific file in the Stan library, but the link to this file 404s.
Using the related function wiener_lpdf
as a template (a process put forth in the guidelines), I added
- the file
ddm_lpdf.hpp
to the directory stan/math/prim/prob/
- the line
#include <stan/math/prim/prob/ddm_lpdf.hpp>
to line 74 of the file stan/math/prim/prob.hpp
(to maintain alphabetical ordering)
- the file
ddm_test.cpp
to the directory test/unit/math/prim/prob/
I ran the tests ./runTests.py test/unit
and make test-headers
, as described in the guidelines, and no errors were produced.
My question is: how can I use my new _lpdf function ddm_lpdf
when actually fitting some data through a Stan interface (e.g., CmdStan
or CmdStanR
)?
5 Likes
Hey,
to use it in cmdstan you need to add it to stanc3, which is the compiler/transpiler that translates Stan code to C++ code. This is a one line change in stanc3. stanc3 is written in Ocaml, but no familarity with it is required.
If you can give me an example of a signature in Stan you want to call I can take minute to build you a version. Or can take a few moments to guide you through adding it yourself.
This is unfortunately outdated. We havent gotten to rewriting those parts of guides unfortunately.
3 Likes
Hi, thanks so much for your response!
I’ve made a few attempts at adding the new _lpdf function to stanc3, but unfortunately I was never able to get it to build.
If you have the time and wouldn’t mind guiding me through adding it myself, I’d really appreciate it! I’m planning to add the CDF of this distribution in the near future, so I think it would be useful for me (and perhaps others, too) to be able to test the new addition before potentially causing headaches for you all.
Another approach (less elegant, but requires touching less repositories) is to build CmdStan with your branch of the math library and then configure cmdstanr
to use this CmdStan version. This does not let you directly call the function, but you can define a custom C++ function in your model that is just a thin wrapper - provided that your header files are (indirectly) included in stan/math.hpp
the function will be visible for C++ code.
Best of luck!
2 Likes
Sorry for the delay in response, and I really appreciate your efforts in helping me test the new _lpdf
function.
I now have the corresponding _lcdf
function that I would also like to add to the Stan Math Library. Using existing functions as templates, I added tests for the new _lcdf
function, so that both of the new _lpdf
and _lcdf
functions have tests; all of these tests pass. Unfortunately, I have remained unsuccessful in attempting to test these new functions in a Stan interface.
If it’s possible to have a bit more guidance on testing these functions in a Stan interface, I’d really appreciate any specific steps (or code) that you could provide. Alternatively, if this is the appropriate time for me to submit a pull request, I am happy to move forward with that.
Thank you again for your help!
1 Like
Hi,
I am far from the authority on this, but since others didn’t respond: it is AFAIK generally OK (even common) to submit a pull request to the math
repo without any accompanying code tests for the interfaces - as long as the functions work and are tested within math
, it is enough. Integrating with the language (and interfaces) is then usually treated as a separate issue and I would expect other devs to help you with that once the math PR is merged.
EDIT: One more thing: it is usually best to start work on a proposed math feature by filing an issue (as discussed at math/CONTRIBUTING.md at develop · stan-dev/math · GitHub). This lets other developers discuss the design you propose before you implement it and can save everybody a bit of work and avoid the unpleasant situation where you’ve invested a lot of work into a feature that for some reason cannot be accepted or needs substantial rework before it can be accepted.
Thanks for working on this and hope the PR goes smoothly!