funko-unko

Here is an MWE: **Stan** ```stan parameters { real x; } model { x ~ normal(0,1); } generated quantities{ if(x < 0){ reject(1); } real y = x; } ```...

> technically, for things in stan/services, you should file an issue on repo stan. and this sounds like a feature where a design-doc proposal might be required. Yes, it affects...

Thanks. The design doc and tests should be most of the work, I already have an implementation that exactly mirrors the gq-implementation. Right now I'm trying to figure out how...

Right, I was hoping to copy most of the documentation from `generate_quantities`, as the interface would be identical :)

Hm, alright I finished the implementation and added some tests. What gets tested so far: **Interface:** * For the return code test this https://github.com/funko-unko/cmdstan/blob/feature/issue-1012-add-log_prob_grad/src/test/interface/log_prob_grad_test.cpp mimics and slightly extends/fixes the original...

> there are a lot of questions that need to be answered about how performant this is going to be. Hm, performance wise it appears to introduce much less overhead...

Hm, so how should I proceed? The design doc Readme suggests opening a discourse thread, I guess my task now is to chill? Edit: CmdStan has so few top level...

Thanks @bob-carpenter and @mitzimorris for the time and feedback. > you can also create a design doc, and then submit a PR - discussion proceeds in the PR comments. >...

@bob-carpenter @mitzimorris Just a short heads up: * Calling `log_prob_grad` draw by draw (as pystan currently has to do) is slower using my current cmdstan implementation than using pystan, i.e....

I remember it being quite annoying to nest different calls to `MaybeDictToFilePath` to ensure deletion of the temporary json files.