You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am a bit confused by the current implementation of the _final_aggregation function used by PearsonCorrCoef, and the reference link in the current docstring is broken.
A quick description of how to implement a parallel algorithm for aggregating running statistics for calculating Pearson correlation is given on the Wikipedia page for variance calculation algorithms. More detailed derivations and analysis can be found in papers by Chan et al. and Schubert et al. (which are cited by the Wikipedia article).
While the current implementation indeed simplifies to the equations provided by these references, it is significantly more complex (and difficult to understand). Is there any reason that I am overlooking (e.g., numerical precision, avoiding overflow) for this specific implementation?
Below is a simplified implementation which I believe matches the output of the current (I have tested on my own data and it passes the torchmetrics unit tests), but is more closely aligned with the source algorithms. If there is no reason for the current implementation, would it be worthwhile to replace with this simpler implementation?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I am a bit confused by the current implementation of the
_final_aggregation
function used byPearsonCorrCoef
, and the reference link in the current docstring is broken.A quick description of how to implement a parallel algorithm for aggregating running statistics for calculating Pearson correlation is given on the Wikipedia page for variance calculation algorithms. More detailed derivations and analysis can be found in papers by Chan et al. and Schubert et al. (which are cited by the Wikipedia article).
While the current implementation indeed simplifies to the equations provided by these references, it is significantly more complex (and difficult to understand). Is there any reason that I am overlooking (e.g., numerical precision, avoiding overflow) for this specific implementation?
Below is a simplified implementation which I believe matches the output of the current (I have tested on my own data and it passes the torchmetrics unit tests), but is more closely aligned with the source algorithms. If there is no reason for the current implementation, would it be worthwhile to replace with this simpler implementation?
Beta Was this translation helpful? Give feedback.
All reactions