Create WelchConfig object
This allows welch_pgram to use a predefined set of configuration parameters in an object named WelchConfig, rather than passing these configuration values by keyword argument. FFT plans and intermediate buffers are preconfigured in WelchConfig making repeated calls that use the same config object faster.
This also sets MTConfig and WelchConfig to be children of the abstract type AbstractPGramConfig
- To see the specific tasks where the Asana app for GitHub is being used, see below:
- https://app.asana.com/0/0/1204607356620460
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
be1a084) 97.56% compared to head (3f356c0) 97.58%. Report is 6 commits behind head on master.
Additional details and impacted files
@@ Coverage Diff @@
## master #502 +/- ##
==========================================
+ Coverage 97.56% 97.58% +0.01%
==========================================
Files 18 18
Lines 3124 3147 +23
==========================================
+ Hits 3048 3071 +23
Misses 76 76
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Should we introduce
periodogram(s::AbstractVector{T}, config::WelchConfig) where T<:Number = welch_pgram(s, config)
periodogram(signal::AbstractVector, config::MTConfig) = mt_pgram(signal, config)
? I'm not sufficiently familiar with these functions to tell whether this makes sense, but if it doesn't, the common supertype AbstractPGramConfig would be questionable as well.
On the topic of abstract supertypes, Filter doesn't seem to be doing anything
On the topic of abstract supertypes,
Filterdoesn't seem to be doing anything
True. I wouldn't mind it being deleted if it bothers you.
With so many configs lying around, would it be good to also add configs for Periodogram and Periodogram2? I mean, not in this PR, of course.