How to test new _lpdf function added to Stan Math through Stan interface?

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 ./ 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)?



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.


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!


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

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/ 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!