Fix rolling correctness edge cases - #61
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Rolling calculations could return incorrect results for extreme finite values, missing weighted products, and large strides. This PR fixes those cases while retaining ordinary arithmetic and incremental calculations where they are appropriate.
n, including an explicitly suppliedNULLor invalid window size.na.rmmodes.Performance
The primary comparison now covers one million values with 5–99 nonuniform weights, plus missing values, unnormalized weights, matrices, strides, ten million values, and unweighted controls. Representative serial timings for 20 weights are:
Remaining costs are explicit: NA-heavy weighted means and extrema are still about 16–32% slower than the PR base in the serial comparison. The guarded unweighted product control also retains overhead. These should take priority over further rare-case optimization; this is not a blanket claim of regression-free performance.
See the common-workload report and reproduction instructions for all results, including two-thread and 14-thread comparisons. Earlier correctness/performance and short-result dispatch reports document the preceding changes and numerical constraints.
Validation
NaN * NA. Explicit regressions cover both operand orders; both original failures were reproduced with an Intel build before correcting the reference.R CMD check --as-cran --no-manual: no errors or warnings; only the development-version metadata NOTE.1e-8; six paired timing batches per case, with raw measurements retained. Builds, tests, and timing runs were kept separate.