-
-
Notifications
You must be signed in to change notification settings - Fork 188
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
feature request: reality check of formula #1708
Comments
I like the idea! I will have to think of specific rules that would make sense here. |
Thanks! That's very understandable. If there are any legit scenarios where this is reasonable, it could be a warning (e.g. "we noticed that your response variable is also a predictor, consider carefully if this makes sense in your case.") instead of alright stop. |
Yes, indeed. I would only throw a warning. |
Understandable. I know brms strives to be quite unrestrictive. Out of curiosity, are there any instances where formulas like this might make sense? I can't think of any. |
I am not sure either, but I will think about it :-D |
I noticed that if you specify a formula in either of these two ways
Response ~ Predictor + Response
Response ~ Predictor + (1|Response + Group)
brms::brm() still runs, though naturally both cases generate various warnings that should be heeded.
I can't think of any circumstances where these formulas would make sense (let me know if there are any!), and it should be relatively easy for brms::brm to do a reality check and not proceed if the formulas look like this (or generate a specific warning about formula specification).
Yes, obviously this is something that people shouldn't do. I happened across it as I was running multiple models and copy-pasting poorly and then trying to understand the weird results.
The text was updated successfully, but these errors were encountered: