Feat/nan policy signal processing 303 - #338
Conversation
Current entries are not touched. Additional entries check for non-finite, or non-nan values, and reject one that could spoil/corrupt filters' states.
…l_processing_303 # Conflicts: # crates/multicalc/tutorials/signal-processing.md
| //! timestep in seconds, and takes frequencies in hertz. A filter is configured once, with the | ||
| //! configuration checked up front, and every call after that is total. | ||
| //! configuration checked up front, and every call after that is infallible: it never panics, never | ||
| //! allocates, and never returns an error. |
There was a problem hiding this comment.
reduce the walls of text everywhere in this PR to be minimal. They are noise and distract from actual code.
There was a problem hiding this comment.
I trimmed away a few hundred lines. Most added codes, apart from tests ~ 50% of added lines, are now doctests, and actual codes account for ~ 1/3 of the src/signal_processing.rs. The actual codes are just checked entry points for core filter methods. They are not technically difficult to implement. But it is the behavior of filters when fed NAN or INFINITY or both worth noting as these could vary filter by filter. Furthermore, as the state of signal_processing kinda doc-heavy, do you want to further reduce the content of these doctests?
P/S: the CI failed to run due to a test numerical_derivative::proptest_ad_fd_single_first stdout. It is not from this PR. So I'll wait for your instruction.
…behaviour, handling NaN following kmolan#338 pattern
2 participants
What & why
Signal filters never panic on non-finite input (
NANorINFINITY) but returned value could be meaningless and filters' states could be corrupted, at worst, till filters' reset.What's new:
multicalc/signal_processing/mod.rsfor new message regarding this behavior;Issue State the NaN policy for
signal_processingand act on it #303Checklist
cargo test+cargo clippy --all-targetsclean locallyunwrap/expect/panicon library paths (typed errors instead)