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

Does the response need to be stored as an FeMat? #250

Closed
dmbates opened this issue Feb 5, 2020 · 5 comments
Closed

Does the response need to be stored as an FeMat? #250

dmbates opened this issue Feb 5, 2020 · 5 comments

Comments

@dmbates
Copy link
Collaborator

dmbates commented Feb 5, 2020

Currently the response is stored as an FeMat in the allterms field of a LinearMixedModel. That was done for convenience back in the days when the random-effects terms were in a separate reterms field from the feterms. By making the response look like a fixed-effects term the feterms had a concrete type of Vector{FeMat{T}}.

This approach has the disadvantage that a model cannot be constructed from a response that is initialized to zeros. There is a check on the rank of an FeMat during its construction and a column of zeros has rank zero. The reason for such a model is for simulations. The simulate! function overwrites the values of the response vector.

It may make more sense make the type of the allterms field Vector{Union{ReMat{T},FeMat{T},Vector{T}}} and skip that check on the rank.

@palday
Copy link
Member

palday commented Feb 5, 2020

I think changing the response to Vector{T} would also make some part of manipulating allterms or more precisely extracting the response, reterms and feterms from allterms easier. You could even use multiple dispatch and avoid conditionals for some things (as the implementation of isnothing does).

Should we warn when constructing a model with constant response? Or perhaps warn when fitting a model with constant response? I'm a strong believer in garbage-in, garbage out, but this type of basic error checking might still be useful.

@palday
Copy link
Member

palday commented Feb 9, 2020

With #253, you can now handle a rank-zero FeMat, so the the disadvantage goes away. That said, I think it might still make sense to store the response as a simple vector because that ultimately what it is right now. But even though this change isn't hard, it isn't free. I can also think of a few potential extensions where having an FeMat as the response would be useful (true multivariate regression; fitting of multiple univariate models in parallel).

@palday
Copy link
Member

palday commented Feb 16, 2020

I think the conclusion we came to was "this is too much effort and FeMat now works for zero-rank matrices", right?

@kliegl
Copy link

kliegl commented Feb 16, 2020

Multivariate extension of LMM was one of Harald Baayen's goals for the Cooperation Group. Linked linear mixed models also come to mind. Just saying ...

@palday palday added this to the MixedModels 4.0 milestone Feb 11, 2021
@dmbates
Copy link
Collaborator Author

dmbates commented Mar 4, 2021

Closed by #464

@dmbates dmbates closed this as completed Mar 4, 2021
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

3 participants