Consider exposing `get_dpar`

[martinmodrak]

Maybe I missed something obvious, but if I understand it correctly, when implementing a custom distribution, one has to suppose that dpars are not themselves predicted or manually write code to detect and handle both the "one global value" and "predicted" cases in their posterior_predict_xx, log_lik_xx implementations.

The built-in distributions use get_dpar that seems to handle this distinction automatically. Maybe it could be exposed to users?

If so, then the custom families vignette should be updated to reflect this.

As usual, if you like then I will (at some point :-) be happy to file a pull request implementing this.

[paul-buerkner]

exposing it sounds like a good idea. Martin Modrák ***@***.***> schrieb am Do., 1. Apr. 2021, 15:08:

…

Maybe I missed something obvious, but if I understand it correctly, when implementing a custom distribution, one has to suppose that dpars are not themselves predicted or manually write code to detect and handle both the "one global value" and "predicted" cases in their posterior_predict_xx, log_lik_xx implementations. The built-in distributions use get_dpar that seems to handle this distinction automatically. Maybe it could be exposed to users? If so, then the custom families vignette should be updated to reflect this. As usual, if you like then I will (at some point :-) be happy to file a pull request implementing this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1131>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADCW2AFB5EH47OJPVUOYWYDTGRV45ANCNFSM42HCCQHQ> .

[paul-buerkner]

Implemented via #1140.