You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The initializeResp function has an incredible amount of crud in it because of design of the glm family objects and in particular the special case of a binomial response specified as a two-column matrix of counts. At present, it is called from plsform but doing so provides absolutely no benefit and it comes are great cost of adding a family argument that should not be there. There is nothing to be gained by adding a family argument to plsform, calling initializeResp and then extracting y, weights and offset from the result yet there is a lot to be lost in terms of a massive increase in complexity encountered when reading the code.
All the messing around with an environment in initializeResp is caused by the brain-dead design of the initialize expression in the glm family argument. Why introduce this totally unnecessary complexity into LMMs when, by definition, a non-trivial family cannot occur.
I'm grumbling about this, fully recognizing that I was the one who created this mess in lme4, but that doesn't mean we have to propagate the mistakes of my youth into lme4pureR :-)
The text was updated successfully, but these errors were encountered:
"There is nothing to be gained by adding a family argument to plsform" This is a good point. I agree. I like the idea of having formula parsing be identical for both pls and pirls.
"All the messing around with an environment in initializeResp is caused by the brain-dead design of the initialize expression in the glm family argument. Why introduce this totally unnecessary complexity into LMMs when, by definition, a non-trivial family cannot occur." This is a good point. Do you have any ideas about how to get the family information into pirls?
Sorry for being awol over the last few days. I'm ramping up for teaching.
Hopefully I'll get some time on the weekend to do a bit of an lme4pureR push.
@stevencarlislewalker Thanks for responding in a calm way to my grumbling and sorry about distracting you at the beginning of classes. (As an Emeritus faculty member I must admit that this is my favorite time of year, in part because I can watch everyone else ramp up for classes while I sit back in the late summer sun and read a novel.)
When you say, "I like the idea of having the formula parsing be identical for both pls and pirls." I take it that you are okay with the idea of initializeResp being called by the pirls code only. Is that the case? If so, I am happy to move initializeResp to R/pirls.R and revert the evaluation of y, weights and offset in the list created by plsform (or whatever we end up calling it).
When you ask about how to get the family information into pirls I think we are stuck doing what we did in lme4. All I want is to be able to avoid using initializeResp in the plsform function and have it called, or the code inlined, whichever makes sense, in pirls.
Do you want me to create a branch and implement what I have been considering so that you can see it?
The
initializeResp
function has an incredible amount of crud in it because of design of the glm family objects and in particular the special case of a binomial response specified as a two-column matrix of counts. At present, it is called fromplsform
but doing so provides absolutely no benefit and it comes are great cost of adding afamily
argument that should not be there. There is nothing to be gained by adding afamily
argument to plsform, callinginitializeResp
and then extractingy
,weights
andoffset
from the result yet there is a lot to be lost in terms of a massive increase in complexity encountered when reading the code.All the messing around with an environment in
initializeResp
is caused by the brain-dead design of theinitialize
expression in the glmfamily
argument. Why introduce this totally unnecessary complexity into LMMs when, by definition, a non-trivial family cannot occur.I'm grumbling about this, fully recognizing that I was the one who created this mess in
lme4
, but that doesn't mean we have to propagate the mistakes of my youth intolme4pureR
:-)The text was updated successfully, but these errors were encountered: