AKuederle
commented
3 months ago Documented here now: https://mobgap.readthedocs.io/en/latest/guides/q_and_a.html
Closed AKuederle closed 3 months ago
AKuederle
commented
3 months ago Documented here now: https://mobgap.readthedocs.io/en/latest/guides/q_and_a.html
This issue should serve as a place for general Q&A until we find a better place to document these topics.
Feel free to ask new questions below. Curated answers will be provided by editing the top post.
Q&A
Why per-second value output for CAD/SL/Gaitspeed?
While we only implement Physics based CAD and SL algorithms, which can provide step-level output, in the original algorithm comparison, we also used ML algorithm that estimated the respective values per window of data. The only common ground was to interpolate step based values to per-second values. This seems a little awkward, and also introduces some level of error, but allows to easily replace the physics based algorithms with ML based algorithms.
WB vs LWB vs GS
Fundamentally, we differentiate between walking bouts and gait sequences. Gait sequences are "regions likely to contain gait". They don't follow strict rules, it is basically "whatever the GS detection algorithm think its gait". Walking bouts follow strict defined rules. These rules were defined as part of a consensus process within Mobilise-D and cover things like the minimum number of strides, the allowed break between two strides and others. Because these rules can only be applied once all parameters are calculated, the final WB can be significantly different from the original GSs. We further differentiate between Walking Bout and Level Walking Bout (LWB). The latter is a WB that contains not incline or decline walking. The idea behind this is, that clinically comparable gait parameters can likely only extracted from level walking. However, because the detection of inclines and declines from just a single lower back IMU is challenging, we rarely use this definition and usually do all comparisons on the WB.
Historic Naming: In older standardized data, WBs were referred to as "Continuous Walking Period (CWP)" or "MacroWbs" and Level WBs were called "MicroWBs".
Why do all algorithms store the input on the object? Does this increase memory consumption?
All algorithm objects make the input data available via
self.dataandself.ic_list(and others) available after calling the action method. This is a "convention" that leads to some nice side-effects. This way, the final object has all the information about inputs and outputs. You could write for example a plot func, that just takes the algo instance as input and have all the information available that you need. I also thought about memory consumption in this context, and the reality is, that it won't matter in 99% of the cases. Just storing the object on the instance will not result in an increase in memory consumption. It only stores the reference to the object. This means the only thing that "could" cause issues here, is that as long as the instance with the results attached exists, the original data will not be cleared from memory. But, it basically never happens, that the original data is out of scope and an algorithm object is still in scope, blocking the data deletion. I played around with that a bit (as we are doing the same in gaitmap) and it never was an issue in any of our usecases.