stan-dev
Include prior mean argument to built-in Laplace marginal likelihood functions
Moving part of the discussion from embedded Laplace doc PR https://github.com/stan-dev/docs/pull/874
From issue #3065
Going the other way, we can also provide a simplified interface where the likelihood is not user specified but set ahead of time.
target += laplace_marginal_poisson_log(theta0, *, K_fn, ...);where * is a place-holder for arguments specific to the Poisson likelihood with a log link.
The PR for the doc has now
`y ~ ` **`laplace_marginal_poisson_log`**`(y_index, theta_init, covariance_function, (...))`
This allows using for alpha (theta) a multivariate normal prior with mean 0 and covariance defined by the covariance function. It would be great to be able to define also the mean of the normal prior as there are plenty of cases where the mean is not 0.
Thus a better function signature would be
`y ~ ` **`laplace_marginal_poisson_log`**`(y_index, theta_init, mean, covariance_function, (...))`
In theory, we could also have
`y ~ ` **`laplace_marginal_poisson_log`**`(y_index, theta_init, mean_function, (...), covariance_function, (...))`
but that doesn't improve flexibility of what can be done, potential improvement in numerical stability is small, and additional complexity in implementation is big.
The one with just a vector mean is easy as poisson_log call inside laplace_marginal_poisson_log would be just
poisson_log_lpmf(y | mean + theta)
@charlesm93, @WardBrian, @SteveBronder
The relevant question for the release is if we want this signature to replace the existing ones or be in addition to. If it's a replacement, it has to be done before the release.
Is it also necessary to change the generic laplace_marginal function, or can the user handle this in their own likelihoods?
Not being able to set a mean per observation confused me a lot. I would think that the function allowing to specify a mean vector is far more useful as I can always pass in a vector of zeros (which is data only and thus a thing for free to do is what I would expect).
Probably do this prior to releasing is my personal opinion here.
@WardBrian lets talk about this in the meeting tmrw.
Is it also necessary to change the generic laplace_marginal function, or can the user handle this in their own likelihoods?
No it would just be the specialized wrappers. I think a good answer here is just exposing the general laplace marginal function in the language and hiding the specializations.
@SteveBronder yes, hiding the special functions for now, settle on them how to put them and then exposing them for the next release sounds like a good way forward for now.
Just to document: This was discussed in both the language meeting and Stan: The Gathering earlier today and it was decided we should add mean to these signatures. Separately, we decided it should be before theta_0, possibly moving theta_0 to the end/making it a _tol only argument (https://github.com/stan-dev/stanc3/pull/1521)
We should get rid of laplace_marginal_poisson_2_log_lpmf since the ye argument (offset argument) acts as a prior mean. So now that laplace_marginal_poisson_log_lpmf takes in a prior mean argument, the second likelihood wrapper is redundant. (Yeah, less functions to maintain!) Also, the tests for wrappers can be used to build unit tests where the mean is non-zero.
Note that ye = exp(mean), so you'll need to pass mean as the log of ye.
Is the prior mean argument a scalar or a vector? From the unit tests, I see it's an option to pass a scalar, however the argument is templated---does that mean a vector could be passed?
Ideally both options would be supported: vector for flexibility and scalar to make the autodiff backend a bit more efficient if all elements of theta have the same mean. If we only keep one, it should be vector.
ps: it is these kinds of combinatorics that make it so useful to give users the option to specify their own likelihood....
The C++ allows both a vector and a scalar. In the language, at least initially, I was only going to expose the vector signature