Closed Asanto32 closed 1 month ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 100.00%. Comparing base (
f338fe7
) to head (5a9dfd0
).
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Do we need to have separate functions per filetype with the new reader?
Do we need to have separate functions per filetype with the new reader?
The underlying naming structure for the dictionary is different, so if we want to move to one function we would still need some sort of logic and different loading for the different Measurements in the WatchData
for example
if .gt3x
... reading structure for .gt3x
elif .bin (&& format == GeneActiv?)
... reading structure for GeneActiv
elif .bin (&& format == some_other _format_in_future)
... reading...
"format"
field.
- Actfast tells you what format it detected in the
"format"
field.
Yes, I saw that. So is it better to just have one reader that does
subject1 = actfast.read(file_path)
format_type = subejct1["format"]
if format_type == ....
- The structure of the outputs is the same - you could search for the specific sensors in all output tables to support all future file format additions
But .gt3x doesn't have the ["high_frequency"] and ["low_frequency"], right? It has a unique ["datetime"] for each sensor type (i.e., ["timeseries"][sensor_type
]["datetime"/sensor_type
], vs .bin that has ["high_frequency"/"low_frequency][sensor_type
].
@nx10 since this change comes largely from the change to actfast, would you mind taking the lead on the review for this PR?
Quickly implemented something over at https://github.com/childmindresearch/wristpy/pull/46
Resolves #43
Minor changes to readers.py and poetry files for updated package dependencies. Primarily to add support for actfast 1.0.0