-
Notifications
You must be signed in to change notification settings - Fork 45
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
Make post-hoc analyses of beta weights easier on the user? #59
Comments
Yes, I think it will be very useful to get a single beta value per condition or a matrix of "conditions x repeats" beta values for each voxel. Further, is there a possibility in GLMsingle to directly estimate only one beta value per condition (instead of averaging it later)? My previous explorations with GLMdenoise suggested that concatenating all conditions/repeats into a single GLM (i.e. assuming a single run) instead of fitting it separately for each run (i.e. block diagonal structure of design matrix) leads to a more robust estimate of beta values (higher split-half correlation). |
Thanks for the suggestions. Regarding the issue of setting up the GLM to estimate only one beta value per condition, it isn't really possible given the current architecture of GLMsingle. You are right that there will be numerical differences between the two approahces (single regressor for all trials vs. a separate regressor for each trial). The reason has to do with the statistical properties of the design matrix. In a sense, the whole purpose of GLMsingle is to allow flexibility at the single trial level. I would hope that taking the mean across all trials associated with each condition provides a result that is fairly similar (but not identical), though? |
Yeah, it makes sense and I understand the goals of the GLMsingle. |
I am not entirely clear what you mean by "independently use". If you mean, can you get the library and do things yourself with it? And, can you in other applications use ridge regression? If so, the answer is yes. The library is straightforward; ridge regression is a bit tricky in the details. You could look through the source code to try to see if you understand how things are set up. |
Earlier, I used to save the output of GLMdenoise as nii files, and then use SPM to estimate betas and for group-level analysis. I would now like to get more robust beta values using the HRF library and ridge regression components of GLMsingle, which are not a part of the SPM package. In other words, which part of GLMsingle code should I modify (if possible) so that it does not reorganize my design matrix? |
Hmm, I'm not entirely sure I follow. Perhaps we would need to have a meeting to clarify what you are thinking. It appears you are trying to shoehorn the concepts of GLMsingle into the SPM framework. I am not sure this is possible. For example, the ridge regression approach is fundamentally different from least-squares estimation (and variants thereof that attempt to model autocorrelated noise). However, I suppose, you could take the HRF library and hook that into a more traditional GLM approach... (That might be relatively straightforward.) Perhaps a way forward would be to take the single trial estimates from GLMsingle, perform averaging across the trials associated with a given experimental condition, and then see if you can work with that (i.e., X x Y x Z x C where C are different conditions, and where the values indicate the estimated BOLD response amplitude to each condition). |
Should GLMsingle also provide some help to the user to, e.g., compute condition means? Like, perhaps indexing vectors based on the contents of the design matrix?
The text was updated successfully, but these errors were encountered: