Open Ollie-spoon opened 6 days ago
As a follow up to this, I had a go at tying to modify the code on the pywt repo to allow long double values which I believe correspond to np.float80 which would hopefully give an increased precision and overall lower error, however, this is definitely above my paygrade, I've never used cpython before.
Hi @Ollie-spoon, thanks for the question.
Assuming that it's not user error, is there a way I can modify the dwt code to ensure that the zero points are lower than ~1e-16?
I didn't have the time to check your code in detail, but a relative error of 1e-16 is always expected for float64
operations. However, absolute errors can and should be much smaller if the amplitude of the input arrays isn't ~O(1).
I had a go at tying to modify the code on the pywt repo to allow long double values which I believe correspond to np.float80 which would hopefully give an increased precision
long double
is a huge can of worms, and on Windows and macOS arm64 doesn't increase precision at all. So we almost certainly don't want to deal with that.
What I want to do is use the dwt for denoising, by taking the regions of the detail signals that go to zero with a noiseless signal, and setting these regions to zero on a noisy signal.
Normally if the background floating-point noise is relevant, you use a thresholding function to zero out the elements below some threshold.
I've been using the DWT and it seems like a great tool but I've repeatedly come across this issue where there seems to be floating point error at around 1e-16 rather than at the smallest value that np.float64 can represent, ~1e-300. Additionally, these values seem to contribute to the transform somewhat distorting the signal but more than this it just makes this tool a lot harder to work with.
What I want to do is use the dwt for denoising, by taking the regions of the detail signals that go to zero with a noiseless signal, and setting these regions to zero on a noisy signal. My logic is that the linear nature of the dwt transfomrm should ensure that the signal is not modified but I'm finding that the DWT alone is modifying the signal.
signal:
exp = 0.2*exp(-t/50.850886977157955) + 0.5*exp(-t/139.33995606900018) + 0.3*exp(-t/235.1443946374417)
Plot of my triexponential decay signal decomposed:![dwt_detail_all](https://github.com/PyWavelets/pywt/assets/68749892/e795c6f4-fb12-4a65-b2bc-b8f776d2db90)
Plot of the error between the reconstructed signal subtracted from the original signal:![dwt_reconstruction_error](https://github.com/PyWavelets/pywt/assets/68749892/0b3bfe87-0808-4a8b-bb0a-9f7e76ace4e1)
If this is an error that I have made then fair enough but it has cropped its head up in every single dwt plot that I have produced so I'm leaning away from this conclusion. Assuming that it's not user error, is there a way I can modify the dwt code to ensure that the zero points are lower than ~1e-16?
Code included for completeness: