Merge pull request #213 from philerooski/phil-patch-210

Include package comparison section at end of paper

Author: philerooski

paper/paper.md

@@ -47,7 +47,7 @@ In the case of accelerometer and gyroscope sensors, mhealthtools provides functi
 
 ![The heirarchical organization of mhealthtools. Note that touch screen and camera sensors do not have their own task agnostic feature extraction functions.](figure_one.png)
 
-All modules, whether they operate at the activity or sensor level, provide some level of parameterization to modify the default feature extraction pipeline. This concept is best illustrated by an activity-level module which makes use of both the accelerometer and gyroscope feature extraction functions. For example, `get_tremor_features` is simple enough to compute features when provided with only the input data as a dataframe in a standardized format — while being flexible enough to accept an assemblage of parameters that control signal detrending, frequency filtering, windowing, which feature sets to compute and more. Additionally, it’s possible to modify the order in which certain preprocessing steps are applied or to include external functions within the pipeline.
+All modules, whether they operate at the activity or sensor level, provide some level of parameterization to modify the default feature extraction pipeline. This concept is best illustrated by an activity-level module which makes use of both the accelerometer and gyroscope feature extraction functions. For example, `get_tremor_features` is sufficiently straightforward to compute features when provided with only the input data as a dataframe in a standardized format — while being flexible enough to accept an assemblage of parameters that control signal detrending, frequency filtering, windowing, which feature sets to compute and more. Additionally, it’s possible to modify the order in which certain preprocessing steps are applied or to include external functions within the pipeline.
 
 This flexibility in parameterization is an intentional design choice of the mhealthtools package, made possible by adhering to a consistent functional paradigm. The user is able to easily mix and match components of pipelines which may be designed for extracting features from different activities without needing to worry about potentially inconsistent output formats from those components.
 
@@ -68,4 +68,9 @@ For more information, including how to use custom preprocessing functions as par
 
 Default feature sets are provided for both time and frequency domains. For a full list of features and their definitions, see the _Feature Definitions_ vignette.
 
+# Comparison with Related Packages
+There exist a number of other packages that were built to work with data collected from sensors in a digital health research setting. HeartPy [@paul_van_gent_2019] is a Python package focused on extracting features from PPG data collected through PPG or camera sensors. GaitPy [@czech_2019] is a Python package designed to extract gait features collected by an accelerometer sensor on the lower back. It includes functionality to identify gait bouts (for measurements collected during free-living conditions), implementations of a number of published algorithms for deriving gait features, and a convenience function to visualize gait events. PDkit [@saez-pons_2019] is the package with the most overlap in functionality with mhealthtools. Focused on Parkinson's disease, PDkit aims to provide a broad suite of tools, ranging from convenience functions for loading data from popular Parkinson's digital health datasets, feature extraction on measurements collected during commonly performed tasks in Parkinson's studies, and even functions which attempt to map sensor measurements to Unified Parkinson's Disease Rating Scale (UPDRS) Part III scores, a clinically validated metric for measuring Parkinson's disease progression.
+
+In comparison to these packages, mhealthtools is focused solely on the feature extraction process and tries to offer a transparent and generalizable framework that makes minimal assumptions about how the sensor data was collected and how it should be processed. This is reflected in a function design that caters to both ease of use and extensibility. mhealthtools adopts robust, functional programming practices, such as predictable error handling, function interfaces, and output formats, making the package a good fit for ETL workloads and streaming data. The default features for IMU sensors were chosen to work well in both clinical and free-living contexts, but are otherwise signal agnostic and not chosen with one particular phenotype or activity type in mind (task specific feature extraction functions, such as `get_walk_features`, may make use of default argument values to these otherwise task agnostic feature sets). For these reasons, mhealthtools is useful for both quickly generating feature sets for exploratory analysis as well as coordinating the extraction of features across multiple packages for more advanced data pipelines.
+
 # References