[jhmigueles]

Fixes #101 => reading a .cwa file in chunks did not give the same samples as reading it as a whole. When a .cwa file is read in consecutive chunks, each call started its own time grid at the first sample and stopped at the last raw sample. The grid of the next chunk was therefore shifted by a fraction of a sample, and one sample could be lost at each chunk border.

Summary of changes

• readAxivity(): output samples now lie on one time grid for the whole file, anchored at header$start and spaced 1 / frequency. A call returns the grid points from the first sample of block start up to the start of block end (but not including it).
• processAxivityBlocks(): two new arguments, fillToNext and gridTolerance. When a chunk ends before the end of the file, the grid points between its last raw sample and the start of the next block are filled by interpolating towards the first sample of that next block, exactly as a single read would. gridTolerance (0.1 % of a sample period) decides on which side of a block border a grid point falls.

This is the default behaviour, with no new user-facing argument. Reading consecutive block ranges now gives the same samples as reading them in one call. The output changes slightly also for whole-file reads. Timestamps can shift by less than one sample period, because the grid now starts at header$start. Values are interpolated at those times, and the number of rows per call can change by one.

Tests

• test_readAxivity.R: a new test, "chunks of consecutive blocks join like a single read", covers the AX3 and AX6 test files with linear and nearest-neighbour interpolation. It checks that all samples lie on the grid anchored at header$start, and that two chunks (cut at blocks 10, 50 and 100) and three chunks give exactly the same data as one read. The tests of the final-packet path now check that samples fall on the file grid and compare their values with a reference interpolation of the raw packet. Expected values in the existing tests were updated to the new grid.
• test_processAxivityBlocks.R: the reference output now includes the grid points up to the start of block 3, interpolated towards its first sample.

Follow-up needed in GGIR

GGIR reads Axivity files through readAxivity() in blocks, so its test output changes once this is merged and released. tests/testthat/test_greadaccfile.R line 83 has to be updated from 280.53 to 282.87. I will open that PR in GGIR once this one is accepted.

Checklist before merging:

• Existing tests still work (check by running the test suite, e.g. from RStudio).
• Added tests (if you added functionality) or fixed existing test (if you fixed a bug).
• Updated or expanded the documentation.
• Updated release notes in NEWS.md with a user-readable summary. Please, include references to relevant issues or PR discussions.
• Added your name to the contributors lists in the DESCRIPTION file, if you think you made a significant contribution.

[vincentvanhees]

GGIR reads Axivity files through readAxivity() in blocks, so its test output changes once this is merged and released. tests/testthat/test_greadaccfile.R line 83 has to be updated from 280.53 to 282.87. I will open that PR in GGIR once this one is accepted.

That would break GGIR tests in the intermediate period, e.g. CRAN does not tolerate that. Order the updates in a way that at no point in time tests have to fail.

Proposal:

Remove L62, L83, and L150, and replace them with a check that the object type is what we expect (matrix or data.frame I think?), and that it has at least 1 row of data. The tests on L62, L83, L150 should not be in GGIR, because it is the responsibility of GGIRread to test that it provides consistent output.

In this way any future improvement to GGIRread::readAxivity, GGIRread::readGENEActiv or read.gt3x can be made without directly breaking GGIR tests ... as long as something fundamental as object type doesn't change.

[vincentvanhees]

I have now addressed this in GGIR commit wadpac/GGIR@f2dc45b
and that will be part of the GGIR 3.4-0 release I will submit to CRAN tomorrow.