# Variable reset time **URL:** \ **Category:** Support\ **Created:** [September 11, 2024, 10:34pm UTC](https://mworks.discourse.group/t/variable-reset-time/1035 "2024-09-11T22:34:30Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![hokysung](https://avatars.discourse-cdn.com/v4/letter/h/ac8455/32.png) [@hokysung](https://mworks.discourse.group/u/hokysung)\ **Post date:** [September 11, 2024, 10:34pm UTC](https://mworks.discourse.group/t/variable-reset-time/1035/1 "2024-09-11T22:34:30Z")
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. ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [September 12, 2024, 3:46pm UTC](https://mworks.discourse.group/t/variable-reset-time/1035/2 "2024-09-12T15:46:33Z")
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](https://mworks.github.io/documentation/latest/reference/sysvars.html) 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](https://mworks.github.io/documentation/latest/reference/sysvars.html#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. I hope that helps! Cheers, Chris ---
**Author:** ![hokysung](https://avatars.discourse-cdn.com/v4/letter/h/ac8455/32.png) [@hokysung](https://mworks.discourse.group/u/hokysung)\ **Post date:** [September 12, 2024, 10:40pm UTC](https://mworks.discourse.group/t/variable-reset-time/1035/3 "2024-09-12T22:40:24Z")
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 ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [September 16, 2024, 12:34pm UTC](https://mworks.discourse.group/t/variable-reset-time/1035/4 "2024-09-16T12:34:34Z")
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](https://github.com/mworks/mworks-issues/issues/462) and will think about it. Cheers, Chris ---
**Author:** ![hokysung](https://avatars.discourse-cdn.com/v4/letter/h/ac8455/32.png) [@hokysung](https://mworks.discourse.group/u/hokysung)\ **Post date:** [September 18, 2024, 3:27pm UTC](https://mworks.discourse.group/t/variable-reset-time/1035/5 "2024-09-18T15:27:20Z")
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. ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [September 20, 2024, 1:16pm UTC](https://mworks.discourse.group/t/variable-reset-time/1035/6 "2024-09-20T13:16:47Z")
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 ---
**Author:** ![hokysung](https://avatars.discourse-cdn.com/v4/letter/h/ac8455/32.png) [@hokysung](https://mworks.discourse.group/u/hokysung)\ **Post date:** [September 21, 2024, 11:16pm UTC](https://mworks.discourse.group/t/variable-reset-time/1035/7 "2024-09-21T23:16:33Z")
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 ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [September 24, 2024, 1:18pm UTC](https://mworks.discourse.group/t/variable-reset-time/1035/8 "2024-09-24T13:18:33Z")
> 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](https://github.com/mworks/mworks-issues/issues/464) for this, too. Cheers, Chris ---
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [October 28, 2024, 4:25pm UTC](https://mworks.discourse.group/t/variable-reset-time/1035/9 "2024-10-28T16:25:23Z")