Test various dsp methods #525
Conversation
Unit tests for dsp methods that do not need to be adapted for complex signals
adapt decibel, time_shift, and pad_zero tests
add a complex plus impulse fixture, implement phase test for complex signals
| 20*np.log10(np.abs(test_Signal.freq))) | ||
| npt.assert_equal(pf.dsp.decibel(test_Signal, domain='freq_raw'), | ||
| 20*np.log10(np.abs(test_Signal.freq_raw))) | ||
| # Testing overwrite log_prefix Parameter |
There was a problem hiding this comment.
It might be possible to remove all tests below, since they are already tested above
There was a problem hiding this comment.
But not for complex signals, or do I miss something here?
There was a problem hiding this comment.
I thought it might not be necessary to test all options of the function with complex signals. For example it should be enough testing the log_prefix with one signal. It's also fine to have it in there, but it might save time for further pulls to have an eye on this.
| # check if results if still complex | ||
| assert padded.complex is True | ||
|
|
||
| desired = pyfar.signals.impulse( |
There was a problem hiding this comment.
Might be possible to remove all tests below since they are already tested above.
| freqs, times, spectro = pf.dsp.spectrogram(signal, window='rect') | ||
|
|
||
| # check frequencies and times | ||
| npt.assert_allclose(freqs, |
There was a problem hiding this comment.
I would suggest to re-arange the data in spectro and freq using np.fft.fftshift to force zero Hz to be in the center of the spectrum. You coud than assert if freqs equal signal.frequencies. This would be more consistent.
remove leftovers
apply fft shift to frequency and spectogramm
pyfar/dsp/dsp.py
Outdated
| @@ -1985,6 +1995,14 @@ def average(signal, mode='linear', caxis=None, weights=None, keepdims=False, | |||
| f"mode is '{mode}' and signal is type '{signal.__class__}'" | |||
| " but must be of type 'Signal' or 'FrequencyData'.")) | |||
|
|
|||
| if ((type(signal) is pyfar.TimeData or type(signal) is pyfar.Signal) | |||
There was a problem hiding this comment.
I understand this for TimeData, but why are the modes not defined for complex Signals?
There was a problem hiding this comment.
Sorry for that. At the very beginning we said it. But with the last discussion this mode restriction is not necessary anymore. I removed it
Which issue(s) are closed by this pull request?
Closes #
Changes proposed in this pull request: