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

Propose architecture for gamma delays #21

Closed
kgostic opened this issue May 13, 2024 · 3 comments · Fixed by #70
Closed

Propose architecture for gamma delays #21

kgostic opened this issue May 13, 2024 · 3 comments · Fixed by #70
Assignees
Labels
enhancement New feature or request infrastructure

Comments

@kgostic
Copy link
Collaborator

kgostic commented May 13, 2024

Goal

Currently the package only estimates lognormal delays. We'd like to add the ability to estimate gamma delays. We'd like to think through how to architect the ability to estimate more than one kind of model.

Specifically, we need functions that can:

  • Estimate gamma and lognormal delays
  • Process the output of a gamma or lognormal brms fit and transform/retrun the estimated parameters into {mean/sd; distribution-specific parameters on the natural scale; distribution-specific parameters on the log scale}
  • Summarize the transformed outputs into quantiles
  • Make some plots of the distribution and parameter estimates

Describe the solution you'd like

  • The easiest approach is to hard-code separate models and post-processing functions for the gamma and lognormal distributions, but this is clunky and inelegant
  • Let's read about R classes and brms families to think through whether there's a better architectural solution that can be implemented with relatively light effort while we're starting

Scope

  • Read about implementation options
  • Draft a proposal for implementation in a new issue
  • Tag @seabbs and Katie for review before starting to implement
@seabbs
Copy link
Contributor

seabbs commented May 13, 2024

{mean/sd; distribution-specific parameters on the natural scal

We discussed whether or not we wanted to do this last week and didn't reach a firm conclusion IMO. I would vote for not providing this as functionality initially (i.e make it another issue with its own place in a dev roadmap) until we have a good idea of how to implement it in a generic way (as can easily do it in a given use case with some thought. That being said could easily go either way.

@kgostic
Copy link
Collaborator Author

kgostic commented May 13, 2024

That's fair. I put it here though, because it should be on the long-term horizon guiding our decisions now.

@seabbs
Copy link
Contributor

seabbs commented May 13, 2024

Agree but in the interest of modularisation of issues we agree its out of scope for a PR targeting this issue?

I also think the first issue we need here is establishing the framework for just the lognormal and once that is PR'd this can be addressed.

@athowes athowes added enhancement New feature or request infrastructure labels May 14, 2024
@athowes athowes self-assigned this May 30, 2024
@athowes athowes mentioned this issue Jun 4, 2024
9 tasks
@seabbs seabbs closed this as completed in #70 Jun 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request infrastructure
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants