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

Flexible grouping of monotonic effects #901

Closed
fusaroli opened this issue May 17, 2020 · 5 comments
Closed

Flexible grouping of monotonic effects #901

fusaroli opened this issue May 17, 2020 · 5 comments

Comments

@fusaroli
Copy link
Contributor

TL;DR: is there (or should there be) a more elegant way to indicate grouping of varying effects when dealing with monotonic predictors?

I have a btw participants design and I am interested in how participant learn over time in the two conditions.
This is the fixed structure:

correct ~ 0 + condition + condition:mo(trial)

Now I want to allow the intercept and slope to vary by participant, but making sure this is done by condition (aka grouping by condition):

Option 1:
(0 + condition + condition:mo(trial)|ID)
Upsides: it works.
Downsides: it models both intercepts and slope by condition for each participant (although they are only in one condition). Also the correlations are fully calculated (and overparameterize the model).

Option 2: the one I'd want to work
(1 + mo(trial)| gr(ID, by=condition))
Upsides: it tells the model there are 2 between participants groups and doesn't overparameterize the model.
Downsides: it doesn't work as mo(trial) is not part of the fixed structure.

Option 3: rewriting the fixed effects
correct ~ 1 + condition + mo(trial) + condition:mo(trial) + (1 + mo(trial)| gr(ID, by=condition))
Upsides: it should work (has worked before, just not sampling in this case) and it shouldn't overparameterize.
Downsides: it's very inelegant. it's not obvious that it's doing what it should (i.e. it calls mo(trial) in the varying effects part, which should calculate it separately for the two conditions; but in the fixed effects part it only denotes learning in condition 1)

@paul-buerkner
Copy link
Owner

I understand that what you want in (2) is (when fully written out):

correct ~ 0 + condition + condition:mo(trial) + (1 + mo(trial)| gr(ID, by=condition))

right? This would indeed be sensible modeling wise (e.g., when coded up directly in Stan), but theoretically hard to archieve in the current software architecture of brms and structure of monotonic effects. The problem is that currently the monotonic random effects inherit their shape (non-linearity) parameters from the corresponding fixed effect. If we don't have a syntactically identifiable fixed effect, we don't know where to inherit their shape from. Of course, they could use their own shape, but this then becomes qualitatively different than other almost equivalent formulas with inheriting shapes.

Suggestions how to deal with this are of your welcome.

@fusaroli
Copy link
Contributor Author

Yes, that's exactly the form I would find most intuitive and that mostly (had a few failures) works when trial is linear and not specified as monotonic.

My intuition was that the form would be identifiable from the syntax, given that the fixed effects structure has the intercept and the monotonic slope both "interacting" with condition, which is also the grouping variable. But I don't have yet any solutions in terms of code to deal with that.

@paul-buerkner
Copy link
Owner

In this very specific case it would be identifiable but this requires looking at the fixed effects, random effects and nesting of group-level effects (because ID is implicitely nested in conditions) to identify the matching. This is way beyond what is reasonable to program into brms. So there needs to be another way to make the identification possible that, perhaps relies on the user giving the identification themselves. Not sure how this would look like and if it was worth it but we can discuss the latter when we have a proposal for the interface.

@fusaroli
Copy link
Contributor Author

that sounds very reasonable (and beyond my current package hacking skills), thanks. I shared on twitter to see if anybody has ideas, and I have a research semester coming, with some time slotted for skill development.

@paul-buerkner
Copy link
Owner

I will close this issue for now to clean up the issue tracker a bit since this isn't high priority.

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

No branches or pull requests

2 participants