stan-dev / stan-dev/rstanarm

posterior_epred for binomial models different than brms

Open
#509 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug question
Dominant language
R
Stars
401
Forks
136
PR merge metrics
No merged PRs in 30d

Description

@bgoodri @paul-buerkner Here's an important different between rstanarm and brms that @lauken13 and I noticed when working on the new MRP package:

Right now rstanarm and brms have different behavior for posterior_epred() for binomial models. In rstanarm we return estimates of p whereas from what I can tell brms seems to return estimates of N * p. Strictly speaking, the brms implementation is more consistent with the name epred in that N*p is the expectation, not p. That said, I find that I pretty much always want p and not N * p when I'm actually using posterior_epred() in practice (e.g., that's what we want for the MRP package). So I think the brms implementation is more faithful to the function name but I find the rstanarm implementation to generally be more useful (at least for MRP and other applications I work on).

How should we reconcile this? It's unfortunate to have different behavior here, but I can see the merits of both.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue concerns posterior_epred() for binomial models and contrasts rstanarm with brms, but it names no files or tests. Start by locating the posterior_epred() implementation and reviewing how its binomial return value is defined. Done means reaching and documenting a decision about returning p versus N * p, then aligning the behavior accordingly.

Written by the indexing model from the issue text.

Assessment

Tech stack
r
Domain
data
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.