MVPA input #172
-
|
Hi, I have a short question regarding the Cross-validation. Thank you for your assistance. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
|
I think it is quite unlikely that the default will lead to any problems. Note that in GLMsingle, it is both the number of nuisance regressors (GLMdenoise) and the amount of ridge regression regularization that are set using cross-validation internal to the GLMsingle algorithm. See also this section from the GLMsingle FAQ (http://glmsingle.readthedocs.io): |
Beta Was this translation helpful? Give feedback.
-
|
That being said, the issue may be tricky/subtle, so if you have a specific scenario that seems problematic, we can delve into it more |
Beta Was this translation helpful? Give feedback.
-
|
Hello,
Thanks for the nice detailed description. A few thoughts:
- Regarding your previous FIR model approach, it generally makes sense. However, it wasn't entirely clear to me how you went about doing that in terms of the details. For example, which, if any, of the trials did you count as repeats of each other? (Or did you try to conduct a purely single trial FIR analysis?) Also, bear in mind that if you just used a long FIR model to model the entire trial, it by no means attempts to separate any of the overlapping responses (e.g. Encoding response bleeds into the Delay, in theory, depending on the HRF length...)
- Regarding #1, I am not sure. I would suggest using b) or a). c) seems a bit ad hoc and strange.
- Regarding #2, it is not necessary. Specifying repetitions of conditions in GLMsingle is used only to tune the hyperparameters. Just a little bit of it might be sufficient. Ultimately you get single-trial estimates anyway, so the specification of repetitions in a sense doesn't really affect the final outcomes that much. I presume your approach could be to just ensure the 36 trial types get coded with the repetitions that you have for them.
Kendrick
… On Feb 25, 2025, at 10:17 AM, Anna Leah Zier ***@***.***> wrote:
Could you maybe help me with the design matrix after all?
I have read the FAQs, so I technically know that if I have different event durations, I can put those into chunks with fixed durations for all events.
Our design refers to a typical working memory experiment that consists of three task phases, Encoding (1.5 s), Delay (10.5 s) and Response (4.8 s) plus ITIs (alternating between 3.6, 6.0, 8.4). TR is 1.2 s. Supplementary info: our design had 36 different trial types of which 18 trials were displayed per run. One session had 8 runs with 4 sessions per subject.
For our (decoding) analysis we want to focus on the singletrial Delay activity. Encoding and Response are events of no interest (can be modeled with 1 regressor per run). Previously, we typically applied a FIR model and used the betas of the FIR Sticks 7 - 11 (and averaged them), i.e., 8.4 s to 13.2 s, to estimate the Delay activity. We were wondering, how to optimally set up the GLMsingle design.
is it better to model the whole delay activity with a) different regressors (del1, del2, del3); b) the same regressor (del, del, del), c) regressors to distinguish early and late delay phase and are separated by a couple of seconds
I would like to average some of the trial activities (i.e. trial type 1 and 19) later, is it necessary that they have the same regressor in GLMsingle in order to guarantee a useful averaging of the beta maps?
We would be very grateful for a suggestion!
—
Reply to this email directly, view it on GitHub <#172 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAU2DEVVDU5J65EPRVPN2C32RSJQTAVCNFSM6AAAAABXX2XKOKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMZRGUYTMMY>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.

I think it is quite unlikely that the default will lead to any problems. Note that in GLMsingle, it is both the number of nuisance regressors (GLMdenoise) and the amount of ridge regression regularization that are set using cross-validation internal to the GLMsingle algorithm.
See also this section from the GLMsingle FAQ (http://glmsingle.readthedocs.io):