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

Add zero-inflated Beta-binomial distribution #1311

Merged
merged 10 commits into from Mar 10, 2022
Merged

Add zero-inflated Beta-binomial distribution #1311

merged 10 commits into from Mar 10, 2022

Conversation

hdrab127
Copy link
Contributor

@hdrab127 hdrab127 commented Mar 9, 2022

Hey hope this zero-inflated Beta-binomial distribution implementation looks okay for #1243.

Mostly followed https://cran.r-project.org/web/packages/brms/vignettes/brms_customfamilies.html and the other families/code already in brms.

Here's a rough example using it with the data from Example 13.1 of McElreath's Statistical Rethinking: https://hdrab127.github.io/brms-zibb-example/brms_zeroinflated_betabinomial.html#model-4-zero-inflated-beta-binomial.

Happy to make any changes or add further tests/docs if it helps. Keen to learn more brms and contribute where possible as might be using a bit this year.

Sorry about the last four commits, please ignore as they don't actually do anything. Hopefully you can squash them in to one on your end, or I can try. Will squash and use branches next time!

Thanks,
Hayden

@paul-buerkner
Copy link
Owner

Thank you! I will review this PR in the next couple of days :-)

Copy link
Owner

@paul-buerkner paul-buerkner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR appears to be of excellent quality and I have just a few minor comments.

In addition, could you update NEWS and bump the brms version in DESCRIPTION by 0.0.1?

I would like to add you as a contributor. If you don't mind, can you tell me your real name for this purpose?

DESCRIPTION Outdated
@@ -46,6 +46,7 @@ Suggests:
emmeans (>= 1.4.2),
cmdstanr (>= 0.4.0),
projpred (>= 2.0.0),
processx,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why and where do we need processx in this PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, this should be in something separate, if needed at all? It was just throwing a warning in devtools::check as it get’s called on R/backends.R#L633 but wasn’t in the list of suggested packages

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right. This had been added recently. I will add it separately to master.

NAMESPACE Outdated
@@ -607,6 +610,8 @@ importFrom(bridgesampling,bayes_factor)
importFrom(bridgesampling,bridge_sampler)
importFrom(bridgesampling,post_prob)
importFrom(coda,as.mcmc)
importFrom(extraDistr,dbbinom)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you seem to access these function via :: to we need to import them?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What’s the best approach? If we call via :: but the user doesn’t have extraDistr installed they’ll get an error like: Error in loadNamespace(x) : there is no package called ‘extraDistr’ when using loo. But then if we importFrom it means users always have to install extraDistr when installing brms which seems over the top. I’ll remove the importFrom’s and add it to suggests? Or would it be better to try code these density/mass functions in directly in a separate PR to remove the dependency altogether?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having it in Suggests is the most sensible thing to do I think. Perhaps for the functions that require a package unders Suggests could be starting with a brms:::require_package(...) call. I will just add it manually to your PR.

R/distributions.R Outdated Show resolved Hide resolved
R/log_lik.R Outdated Show resolved Hide resolved
R/posterior_predict.R Outdated Show resolved Hide resolved
@hdrab127
Copy link
Contributor Author

hdrab127 commented Mar 9, 2022

Brilliant, thanks for reviewing and all the tips/advice!

Have made those changes (6abc29a) with just a couple follow up questions/comments above.

Full name: Hayden Rabel

Thanks again 👍

@paul-buerkner
Copy link
Owner

Merging now. Thank you very much again for your contribution to brms!

@paul-buerkner paul-buerkner merged commit 9a038e5 into paul-buerkner:master Mar 10, 2022
@paul-buerkner
Copy link
Owner

We are now in the intersting position that we have a zero-inflated beta-binomial family but not a regular beta-binomial family. Of course, the latter is already available via a custom family and featured in the custom family vignette but I think it may be time to make beta-binomial built-in as well. Do you perhaps, by any chance, have the time to implement this as well? No worries if not of course, it just happend to cross my mind.

@hdrab127
Copy link
Contributor Author

hdrab127 commented Mar 11, 2022

Sweet, thanks! brms:::require_package looks good.

Yep, I'll have a go at the regular beta-binomial early next week. Do you think it'd be worth updating that vignette (which was reallly helpful by the way) to a different custom family currently being requested? Like the generalised Poisson (#739) / Pareto (#1113) distribution, or lognormal with natural scale params (#1027)?

Or just make small text edits to reflect that the beta-binomial is [will be] in brms but the custom beta_binomial2 will still work and should produce identical results. Happy to work on either.

@paul-buerkner
Copy link
Owner

paul-buerkner commented Mar 11, 2022

Thank you!

With regard to the vignette, both is fine I think. Changing the example in the vignette of course has the advantage of getting another family available for users. Perhaps the lognormal with mean-SD parameterization could be interesting, but I don't want to cause you even more work. So whatever you feel like doing for this, would be fine by me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants