Update epidist_prior to return all priors including defaults for additional parameters

[athowes]

In PR #95, the version of epidist_prior that we provide is as follows:

epidist_priorA <- function() {
  prior1 <- brms::prior("normal(2, 0.5)", class = "Intercept")
  prior2 <- brms::prior("normal(0.5, 0.5)", class = "Intercept", dpar = "sigma")
  return(prior1 + prior2)
}

Depending on how possible it is to use brms::get_prior in a suitable way, I in this issue I propose that we move to:

epidist_priorB <- function() {
  defaults <- brms::get_prior()
  # check here that defaults actually contains the two intercepts?
  defaults[1] <- "normal(2, 0.5)"
  defaults[2] <- "normal(0.5, 0.5)"
}

Briefly:

• I think that epidist_prior returning all priors used in the model at once is more "natural"
• Allows us to suggest that users call epidist_prior to see all priors used in the model such they may then edit one object
  • This simplifies the workflow suggested in current roxygen2 documentation

(I give my reasons for this preference in the comments for #95, but I think summed up here.)

I'm open to disagreement about this, and other suggestions to improve the epidist prior interface.

[seabbs]

I think a sensible thing to do is check for issues around getting all priors from a brms model and if there isn't one opening one (i.e fixing this at the brms level)

[athowes]

I think a sensible thing to do is check for issues around getting all priors from a brms model and if there isn't one opening one (i.e fixing this at the brms level)

Based on this I am unsure that we are on the same page. I suggest that we clear this up during next meeting over voice.

[athowes]

• Sam A writes:

what if you have a custom wrapper around get_prior?
that merges custom priors into the defaults?
and then pass it to fn?

get_all_priors <- function(...,) {
  defaults <- get_prior(...)
  actual_priors <- defaults - custom_prior #pseudo code
  return(actual_priors)
}

• Agree that best option would be replacement for fn that gets all the priors
• Katie notes it's nice to see priors before running model and priors be comprehensive

[athowes]

This is complete as of #242.