Hi Chris,
I’ve been looking into analyzing the MWorks data.
I’ve successfully gotten to unpacking and obtaining a dataframe consisting of all events. The dataframe has three columns: time, variable, and value, where each row corresponds to an mwk2 event.
I have noticed that there are certain bouts of times when suddenly all of the variables, even ones that do not get updated at all over the session, are re-defined as whatever the previous value of the variable was. I am able to isolate the actual trial_start and trial_end times by filtering only for events that have identical t_start and event timestamp values (since I set t_start = now() in my .mwel code). But there are still sometimes multiple events of all-variable-resets within a trial, which is complicating analysis and processing of the dataframe. I was wondering if there was a robust way to tell if such an all-variable-reset happens or not, e.g. if there was a signature variable that gets set when this happens, and thereby remove / filter them out from the df.
Hi Hokyung,
There are certain times when MWorks automatically announces the values of all variables:
- a new experiment is loaded
- a new event file is opened
- the experiment starts running
- the experiment is closed (in this case, only system variables are announced, because any experiment-defined variables no longer exist)
- a client connects to the server
Note that when these announcements happen, it’s the current (i.e. most-recently assigned) value of each variable that’s announced. Maybe that’s what you meant by “previous value”.
If you’re seeing all-variable announcements in the middle of a trial, it must be because a client connected while the experiment was running.
As for how to filter out such announcements, a couple ideas come to mind:
-
Since no variable values have changed, for each variable, you could look for sequential events with the same value and filter out all but the first. This is probably the most robust approach.
-
You could identify instances of all-variable announcements by looking for #loadedExperiment events. That variable is set only when an experiment is first loaded, so it should only ever appear in an event file as part of an all-variable announcement.
Once you find a #loadedExperiment event, you could try filtering out other events that are very close to it in time. However, there’s no guarantee that a “real” variable assignment won’t have happened in that time range, so you run the risk of discarding events that you want.
I hope that helps!
Cheers,
Chris
Thank you for the pointers!
Sequential events with the same value seems like it won’t work for me as I might be doing “real” variable assignments that overlap, e.g. when deciding on a block type, consecutive blocks might be of the same type.
I suppose filtering around the #loadedExperiment calls together and filtering out again for sequentially identical might be one way to go, though this still runs the risk of removing real events that happen within that window…
Going forwards, would it be possible for there to be an explicit timestamp for when all-variable announcements occur? Or even better, a way to mark all-variable announcement events separately somehow?
Thanks,
Hokyung
Hi Hokyung,
Sequential events with the same value seems like it won’t work for me as I might be doing “real” variable assignments that overlap, e.g. when deciding on a block type, consecutive blocks might be of the same type.
But if the value hasn’t changed, you don’t lose information by discarding those events. When you’re analyzing your data, you should just ask, “What is the value of variable x at time t?” It doesn’t matter if the value was assigned in the current trial or a previous one. You just want the x event closest to, but not after, t.
Going forwards, would it be possible for there to be an explicit timestamp for when all-variable announcements occur?
Even if all the events from an all-variable announcement had the same time stamp, you could still have other events with that time stamp, so that wouldn’t be a robust solution.
Or even better, a way to mark all-variable announcement events separately somehow?
Yeah, it would be best if we could not record them to the event stream at all. I’ve opened an issue and will think about it.
Cheers,
Chris
Hi Chris,
But if the value hasn’t changed, you don’t lose information by discarding those events. When you’re analyzing your data, you should just ask, “What is the value of variable x at time t ?” It doesn’t matter if the value was assigned in the current trial or a previous one. You just want the x event closest to, but not after, t .
I agree this can cover most cases, but I’m not sure it would work for cases when the timing of those repeated choices are important. Assuming the relevant variable happens to be the only one that can indicate when those choices were made, discarding all value-repeats would remove their timing information. I suppose this could be remedied by having a separate variable that tracks the timing of the choices in the .mwel code, but just wanted to point this out.
Hi Hokyung,
Yes, that is a good point.
Another thought: If each variable kept track of the time of its most recent assignment, and if all-variable announcements used those stored time stamps (instead of the current time), then any “duplicate” event created by those announcements would have the same time stamp as the original, actual assignment. That would make them easy to filter out or ignore, as the events would be identical (same time, same value). We might even be able to filter them out automatically, when writing the data file.
Does that sound like it would resolve the problem?
Chris
Hi Chris,
Yes, as far as I can see that seems like a robust solution! Thanks for this.
On a separate note, I was wondering if there was any signature that can tell apart variable change events that I induced during a session by directly changing the value on the Variables window. It would be highly useful for me, for instance, if there was a system variable or the like that could signal whenever a variable change via the Variables window occurs, e.g. the variable name, to distinguish it from events generated by .mwel code.
Thanks,
Hokyung
I was wondering if there was any signature that can tell apart variable change events that I induced during a session by directly changing the value on the Variables window.
No, there is not, but it’s worth considering. I’ve opened an issue for this, too.
Cheers,
Chris