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
uf_designmat looks for 'eventstypes' but using strcmpi(), which ignores case.
Thus, when an event is specified with a wrong case, e.g. cfgDesign.eventtypes = {'sTiMuLuSoNsEt'} % should be 'stimulusOnset'
then the modeling process does start (no error produced initially), but mayhem happens later at the uf_glmfit stage (without producing an explicit error)
The text was updated successfully, but these errors were encountered:
I agree that this is potentially breaking, but it looks like it can't break anything that is not already severly broken.
If an existing user did use an incorrect letter case for any event in the model, they either...
(1) got an immediate error (but this only happens if there is only this one predictor-event in the model!), or (2) got incorrect betas (i.e. zeros for the predictors associated with this event) or, (3) uf_glmfit() seemingly runs forever
Finally, I also saw weird warnings by the solver, but unfortunately cannot reconstruct that scenario (may be the same as the "runs forever" one).
So the downstream consequences of case-insensitivy are bad. For example, the non-time-expanded DM will still look okay, initially (with entries in all columns) but only before uf_epoch is run, which removes the epochs for the misspelled events. For Xdc, colums will be zeroed for the misspelled event.
uf_designmat
looks for 'eventstypes' but usingstrcmpi()
, which ignores case.Thus, when an event is specified with a wrong case, e.g.
cfgDesign.eventtypes = {'sTiMuLuSoNsEt'} % should be 'stimulusOnset'
then the modeling process does start (no error produced initially), but mayhem happens later at the
uf_glmfit
stage (without producing an explicit error)The text was updated successfully, but these errors were encountered: