Closed vincentvanhees closed 1 year ago
Merging #30 (ff3ecaf) into main (77aed86) will increase coverage by
0.06%
. The diff coverage is82.35%
.:exclamation: Current head ff3ecaf differs from pull request most recent head b2c0636. Consider uploading reports for the commit b2c0636 to get more accurate results
:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@ Coverage Diff @@
## main #30 +/- ##
==========================================
+ Coverage 86.72% 86.78% +0.06%
==========================================
Files 9 9
Lines 919 946 +27
==========================================
+ Hits 797 821 +24
- Misses 122 125 +3
Impacted Files | Coverage Δ | |
---|---|---|
R/readAxivity.R | 85.71% <82.35%> (+0.29%) |
:arrow_up: |
This PR fixes #29
As of release 0.2.7 (last week) the code assumed a steady number of samples per block based on sampling rate and file type. This, I now realise, is not a safe assumption for Axivity as it can have a variable sampling rate.
As a result too much data is being skipped when searching for the next block when sampling rate is lower than expected. In the opposite situation when the sampling rate is higher than expected it is not a problem because the code will keep iterating over the blocks until it has found the correct timestamp.
Based on test data I see the error can be around 0.6%. So, I updated the code with an extra safety margin by only skipping 97% of the anticipated data to be skipped. So, for now I assume that the error in sampling rate never gets more than 3% accumulated over time.
UPDATE: I have now revised this to follow the logic: