Brms emmeans Integration (epred=TRUE bernoulli family)

I’ve recently tried using emmeans with epred=TRUE and re_formula=NULL for a bernoulli family brms model and received the following warning:

Warning message:
In mean.default(y) : argument is not numeric or logical: returning NA

Any thoughts on why this occurs with a bernoulli family brms model but not a negative binomial or zero-inflated beta? The warning goes away when I remove epred=TRUE. I’m new to these approaches and may not totally understand what epred=TRUE is doing?

2 Likes

Hi,
I think this might be a bug in emmeans - the brms support for emmeans improved recently, but is probably not complete yet. Are you sure you are using the latest version of both packages? If yes, could you provide a simple reproducible example that anyone can run (i.e. including simulated data and fitting code) to test the problem on their machine? It might be best to actually file that as an issue for emmeans on GitHub.

That’s probably a very important piece of information to understand to let you interpret the results. You may want to check out Draws from the Expected Value of the Posterior Predictive Distribution — posterior_epred.brmsfit • brms and contrast with Draws from the Posterior Predictive Distribution — posterior_predict.brmsfit • brms and Posterior Draws of the Linear Predictor — posterior_linpred.brmsfit • brms

Best of luck with your model!

Thanks! Yes I’m using the latest versions of the packages installed from the CRAN. I posted in the emmeans github and received the following response:

I think perhaps that what is happening is that epred() doesn’t produce numerical predictions. The brms package has its own emmeans support, and you may need to ask the developer of that package for details, and/or ask if the epred option should work.

I’m attaching some data and a reproducible example:

Example.csv (6.5 KB)

install.packages(“brms”)
library(brms)
install.packages(“emmeans”)
library(emmeans)

example<-read.csv(“Example.csv”,header=T)
as.factor(example$ID)->example$ID
as.factor(example$Sex)->example$Sex
as.factor(example$Region)->example$Region
as.factor(example$Presence)->example$Presence

model<-brm(formula=Presence ~ Region + Sex + Age + DD + PMI + (1 | ID), data=example, family=“bernoulli”,warmup=2000,iter=4000,seed=34)

emmeans(model, ~ Region, epred=TRUE, re_formula=NULL)

The warning only appears with a bernoulli model (I’ve run negative binomial and zero-inflated beta without the warning).

Great, thanks for the example. If it is a bug in brms's support for emmeans then please file an issue in the brms repository.

In any case, for almost all practical use cases, it shouldn’t be very difficult to replicate the needed emmeans functionality yourself by directly calling posterior_epred and specifying relevant groups you want to compare as rows in the newdata argument. This way you get posterior samples of predictions for say each region (given other parameters) with which you can then compare/visualise/compute differences as needed.

Best of luck with your project!

I don’t know where this warning is coming from. I get reasonable output from emmeans and posterior_epred called internally does not contain any NAs from what I have seen.

1 Like

@paul.buerkner so does posterior_epred provide the same output as the emmeans call in my reproducible example and I shouldn’t worry about the warning?

I think so but I don’t know where the warning comes from to be honest… my impression was that it wasn’t coming from within brms but I am not sure what causes it exactly. Did you try with binomial and compare the output of emmeans? Do they coincide?

My apologies as I never saw this response. I never ran just a straight binomial model as my data doesn’t exactly have a number of trials but rather represents just presence/absence of lesions in a patient in a particular region. However, when using other data types (ie lesion numbers and lesion areas) and running negative binomial and zero-inflated beta I don’t get any warning.

I also ran into this warning but didn’t pursue it further. Is this something of concern?