Stop times and dynamic variables about pyactigraphy

[roryos1]

This study also shows the dynamic M variables in action - https://pubmed.ncbi.nlm.nih.gov/31288983/

[ghammad]

Dear @roryos1

Thank you for the feedback. Always appreciated.

Indeed, there is no way to specify the stop time directly (I don't recall why I did not include that possibility from the start...). However, if you know your start time, then it becomes easy to specify a stop time as period=stop-start.
However, I'll include that possibility in the list of changes for next minor release.

A side remark: having a start/stop file is really handy and can be shared along with the data. It is also easier to maintain, modify and store centrally and give access to others working on the same data for example. So I strongly encourage people to use it.

Concerning the MX variables, if I understand correctly what I have read in the reference you provide (and the ref therein, Rowlands et al., 2019), these variables are slightly different from the traditional L5/M10.

L5/M10: average activity counts (or equivalently the average hourly mouvement duration, for binarised data) for the uninterrupted least/most active 5h/10h-period (https://journals.sagepub.com/doi/pdf/10.1177/074873049701200206)

MXacc: magnitude of acceleration above which X most active minutes are accumulated. But if I understand correctly, there is no continuity requirement about these most active minutes.

These variables are anyway interesting but we need to find a new name, in order to avoid the confusion...

[roryos1]

Dear @ghammad,

Thank you for your prompt response.

Sorry yes, the MX variables and traditional L5/M10 variables are calculated differently. I believe both continuous/accumulated variables are informative, and definitely provide more specific data about an individual's activity profile when <10 hours. Does this seem like a good idea to you? Not strictly related to circadian rhythm but possibly a good way to diversify the package to measure activity profiles throughout the day.

[ghammad]

Dear @roryos1

Indeed, these metrics would be a valuable addition to the package.

I see two ways to proceed further now;

1. if you can, you can code the variables and submit a PR
2. I code them for the next release but I cannot promise anything about the timescale...

The choice depends on your agenda.

Anyway, thanks for bringing these variables to my attention and good luck with your analysis.

[roryos1]

Dear @ghammad,

I believe you are much better suited to coding these variables than me, do not worry about the timescale. I have a couple of other questions about the package which I'll put into a new thread (to keep the focus of this thread).