Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider setting intercept on any distributional parameters without a model #266

Closed
athowes opened this issue Aug 29, 2024 · 1 comment · Fixed by #370
Closed

Consider setting intercept on any distributional parameters without a model #266

athowes opened this issue Aug 29, 2024 · 1 comment · Fixed by #370
Assignees
Labels
high Required for next release

Comments

@athowes
Copy link
Collaborator

athowes commented Aug 29, 2024

In PR #255 we moved to allowing bf(mu ~ 1) to be the default for the formula option of epidist().

This means that users now do not need to specify a model on the distributional parameters of the model (aside from mu) if they don't want to.

Although this is nice, it does now mean that:

  1. We must be specifying priors on both the Intercept_dpar and dpar parameters in epidist_family_prior()
  2. If we have any post-processing which relies on knowing model names (e.g. Intercept_dpar) then it'll be more fiddly

An alternative proposal is to set dpar ~ 1 for any dpar left without a model. This would fix the two problems above but introduce its own problems:

  1. Users may be confused that we've changed their model in the output
  2. If a user puts a prior on dpar as an override then it won't easily work with the new Intercept_dpar parameter. Further: perhaps it's good to allow users to be putting priors on the distributional parameter itself, rather than the intercept

For the time being I'm happy to stick with things as they are, but if the downsides become more painful for some reason I could be convinced to switch approaches.

@athowes athowes added the wontfix This will not be worked on label Aug 29, 2024
@seabbs
Copy link
Contributor

seabbs commented Aug 29, 2024

I think this is a nice summary and I think the only way we can decide this is to confront some users with the current design and ask them.

@athowes athowes added high Required for next release and removed wontfix This will not be worked on labels Oct 10, 2024
@athowes athowes self-assigned this Oct 10, 2024
seabbs pushed a commit that referenced this issue Oct 10, 2024
* Scope notes on forcing a ~ 1 when noting provided

* Update globals.R

* Run document()

* The structure for the .make_intercepts_explicit helper function insertion

* Set-up test and documentation for helper function

* Return formula in placeholder

* First draft of "add ~ 1" functionality

* Trying to test by comparison to explicitly created formula

* Missing bracket

* Don't change the formula for parameters set to be a constant

* Simplify prior structure

* Set environments to NULL such that formulas are equal

* Fix to bug in prior checking test
seabbs pushed a commit that referenced this issue Jan 10, 2025
* Scope notes on forcing a ~ 1 when noting provided

* Update globals.R

* Run document()

* The structure for the .make_intercepts_explicit helper function insertion

* Set-up test and documentation for helper function

* Return formula in placeholder

* First draft of "add ~ 1" functionality

* Trying to test by comparison to explicitly created formula

* Missing bracket

* Don't change the formula for parameters set to be a constant

* Simplify prior structure

* Set environments to NULL such that formulas are equal

* Fix to bug in prior checking test

Former-commit-id: 75f35476372837afd57b961d2deff077ddf18bc4 [formerly 41c3ea535f40cbdb271dcc98f8ed34dfbe059943]
Former-commit-id: 24c26025b125ab109cdad08095fe10d61db9264a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
high Required for next release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants