You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Strange behavior of dwt_coeff_len and dwt_max_level. #877
I'm using PyWavelets1.10.0.
I was trying to find how many dwt levels an input data of length 23 will have.
Based on the while loop printouts, I thought the level for 23 should be 3 rather than 2?
I might have misunderstood what dwt_max_level does if this behavior was intended rather than a bug...
Thank you ahead of time for looking into this!
(btw, pywt.__version__ is still showing 1.8.0 b/c of this line.
With the current source's documented meaning, the original result 2 is consistent. dwt_max_level returns the maximum useful depth for the original signal, using the boundary-effect criterion in its docstring. It is not the number of times an output array can be shortened while a fresh call still returns a positive level.
For db2, the decomposition filter length is 4, so the documented bound is
floor(log2(23 / (4 - 1))) = 2
The coefficient-length rule for symmetric is floor((n + 3) / 2). These two calculations give exactly your loop:
Current array length
Fresh dwt_max_level(n, 4)
Next coefficient length
23
2
13
13
2
8
8
1
5
The later calls treat 13 and 8 as lengths of new input signals. They do not track the boundary effects already carried through previous decomposition stages, so their values cannot be accumulated into a depth budget for the original 23 samples.
To predict lengths at the default useful depth, compute that depth once:
An explicit level=3 is a separate choice: the current Python guard returns it while warning that all coefficients experience boundary effects. This warning behavior was deliberately introduced in #403; dwt_max_level is a useful-depth criterion rather than a hard prohibition on a deeper transform.
I checked the pinned current source, integer length calculations and isolated Python level guard; I did not execute the PyWavelets C/Cython transform or your build, so this does not diagnose the separate __version__ discrepancy. Affiliation: Bharath Healthcare / Pinnacle Blooms Network. Codex assisted with this source inspection, bounded local check and reproducibility-focused reply.
Activity
drkotireddysaripalli commentedon Oct 8, 2026
With the current source's documented meaning, the original result
2is consistent.dwt_max_levelreturns the maximum useful depth for the original signal, using the boundary-effect criterion in its docstring. It is not the number of times an output array can be shortened while a fresh call still returns a positive level.For
db2, the decomposition filter length is4, so the documented bound isThe coefficient-length rule for
symmetricisfloor((n + 3) / 2). These two calculations give exactly your loop:dwt_max_level(n, 4)The later calls treat
13and8as lengths of new input signals. They do not track the boundary effects already carried through previous decomposition stages, so their values cannot be accumulated into a depth budget for the original 23 samples.To predict lengths at the default useful depth, compute that depth once:
wavedecdoes this same one-time level selection from the original axis length. For that case its coefficient-list geometry is[cA2, cD2, cD1], with lengths[8, 8, 13].An explicit
level=3is a separate choice: the current Python guard returns it while warning that all coefficients experience boundary effects. This warning behavior was deliberately introduced in #403;dwt_max_levelis a useful-depth criterion rather than a hard prohibition on a deeper transform.I checked the pinned current source, integer length calculations and isolated Python level guard; I did not execute the PyWavelets C/Cython transform or your build, so this does not diagnose the separate
__version__discrepancy. Affiliation: Bharath Healthcare / Pinnacle Blooms Network. Codex assisted with this source inspection, bounded local check and reproducibility-focused reply.