add `sliding_window_maxima`
Feature addition: add iterator whose elements are maxima of a sliding window over an original iterator.
Codecov Report
:x: Patch coverage is 98.64865% with 1 line in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 91.96%. Comparing base (568d12c) to head (b589762).
| Files with missing lines | Patch % | Lines |
|---|---|---|
| src/IterTools.jl | 98.64% | 1 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## master #126 +/- ##
==========================================
+ Coverage 90.72% 91.96% +1.23%
==========================================
Files 1 1
Lines 399 473 +74
==========================================
+ Hits 362 435 +73
- Misses 37 38 +1
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
why does this have some very aggressive compiler directives thoughout it?
these are going to require careful hand checking. The compiler can normally work things out.
why does this have some very aggressive compiler directives
-
~~The
@assume_effects :terminates_locallyis for the loops. The compiler currently does not attempt to prove termination of any loop, see Julia issue https://github.com/JuliaLang/julia/issues/57097. Theterminateseffect is necessary for both dead code elimination and for constant folding, see the@assume_effectsdoc string. The:terminates_locally, as opposed to:terminates_globally, only applies to the local loops, so I'd say the directives are correct.~~ EDIT: the PR doesn't doassume_effectsany more. -
The
@constprop :aggressivedirectives were necessary (some of them, at least) to make the test suite (the@inferred, to be specific) pass on some versions of Julia (v1.8, at least). We definitely want constant propagation to happen, and these directives are not dangerous (in contrast to@assume_effects), so applying them seems like a no-brainer. The worst these can cause is excessive compilation latency, so I think excessive scrutiny of@constprop :aggressivemight just be premature (compile-time) optimization.
bump
bump
sorry, its just i am not sure if this belongs in this package or not. It's a very intricate function.