I was checking out the mathworks site for the new version of the CWT function http://www.mathworks.com/help/wavelet/ref/cwt.html and realised that cwt no longer supports user selectable wavelets such as cmorx.x, dbx, dmey etc. You only have three options : morse', 'amor', and 'bump'
Moreover you no longer can obtain the CWT of a signal at a specified scale, or, for that matter, at user selectable scales likewise c=cwt(signal,'scales,wavelet_type)
Strangely enough in the r2016b WaveletAnalyzer(ex wavemenu) the wavelet selection includes all the previous wavelets (cmorx.x, dbx, dmey, gaussx, haar). Moreover the user can select the scale, likewise in the old cwt.
Does that mean that there is no command line cwt command that apply these wavelets, and user scale selection???
The R2016b release notes say
Continuous Wavelet Transform: Analyze signals with improved automatic selection of wavelet and scales
This release provides an updated version of the continuous wavelet transform, cwt, and a new inverse transform, icwt, for reconstructing the original signal. These functions are easier to use because they have simple interfaces and include default values for the wavelet and scales and frequency and period ranges are easy to specify. When you use the updated cwt, which use analytic wavelets and L1 normalization, icwt produce a more accurate reconstruction.
The old version of cwt continues to work, however, updating existing code to use the new version of cwt is recommended. Both the old and updated versions use the same function name. The inputs to the function determine automatically which version is used.
The documentation page for cwt says you can also look at https://www.mathworks.com/help/wavelet/ref/cwtold.html
Paramonte, I posted this response on another thread where you posted a comment. I will repeat the essential content here. As I said in the other post, I would be very interested in engaging with you so please do contact me.
There was already CWTFT in the toolbox for a number of releases that used an FFT-based algorithm (that DFT-based approach to the CWT long preceded Torrence and Compo by the way). The new CWT algorithm features Morse wavelets, which have parameters that can be adjusted to give a very large family of analytic wavelets. In fact, most analytic wavelets in use are just special cases of Morse wavelets as was proved by Lilly and Olhede. We have received a lot of feedback from customers that they are confused by having to specify scales and in fact they quite often get the scale concept wrong and use scales that don't allow them to actually find the phenomena they are looking for. The old CWT had absolutely no defaults. The user had the burden of specifying everything. As I mentioned for many non-experts, having to pick a wavelet was daunting, never mind having to construct a meaningful scale vector. Scale for the wavelet transform should be logarithmically spaced for example and the scales should take into account the support of the wavelet. Neither of those things were built into the old CWT.
For time-frequency (time-scale) analysis which is a major use case for continuous wavelet analysis, many of the orthogonal or biorthogonal wavelets which are quite useful for discrete analysis are inappropriate and lead in many instances to people obtaining a misleading analysis of their data. Orthogonal and biorthogonal wavelets are designed for dyadic scales, which are much more widely spaced that the typical scales in continuous wavelet analysis.
Having said all that, if you want to use the old CWT, that interface still works. In fact, the new CWT parses the input and determines if you are using the old syntax. If so, it will give you the older algorithm. I would sincerely welcome the opportunity to discuss these things further. Feel free to contact me through my profile. I will respond. I would very much be interested in any specific use cases where the old CWT allows one to obtain some insight not obtainable with the new CWT. I am always very interested in getting feedback from users on how to make things better.
We never "not recommend" something lightly. That is not to say that somehow we are infallible, but a lot of thought and customer feedback goes into those decisions.
Hope that helps, Wayne
Dear Paramonte, with respect to naming this is always a hard decision. The acronym CWT is well established so users look for it. Users also expressed some confusion at why we had CWT and CWTFT, and which one should they use. The new CWT algorithm also lends itself to an inverse algorithm which the old one did not, so now we have CWT and ICWT for the inverse. The ICWT accepts a frequency or period band input so you can do a frequency-localized reconstruction.
As I suggested, we specifically implemented the new CWT in a way that you can simply call the old one if you wish.
I would welcome a detailed discussion with you as I offered. But we have seen many users struggle with scale and specifying scales. For example, users will specify scales without taking into account the support of the analyzing wavelet. As a result they would have many scales where the wavelet extended well beyond the extent of their data. So in fact, they had no wavelet at all (there was not even one oscillation in the extent of the data). Or they would similarly use scales which were too small and therefore did not provide any wavelet analysis.
Also, as you are no doubt aware, the scale-to-frequency conversion is not equally good for all wavelets. For the Morse wavelets and the default we use, it is quite good because that wavelet is symmetric and well-localized in the Fourier domain. That is also true of the 'bump' wavelet and 'amor' (Morlet) wavelets supported by the new CWT.
For example, here is the default Morse wavelet in the Fourier domain with a vertical line at its predicted center frequency
omega = 0:0.001:(2*pi); psihat = omega.^20.*0.0051.*exp(-omega.^3); plot(omega,psihat); grid on; hold on; title('Default Morse Wavelet -- Fourier Domain'); plot([(20/3)^(1/3) (20/3)^(1/3)],[0 2.5],'k')
You see that this is perfectly symmetric in the Fourier domain. That is certainly not the case with most of the orthogonal and biorthogonal wavelets, like the 'db' family. In those cases, scale to frequency is not so well defined because the wavelet is not symmetric in the Fourier domain and the bandwidth is much larger.
Also, in the new CWT we use L1 normalization which is much more natural in time-frequency analysis than the L2 normalization used in the older CWT. With L1 normalization, a sine wave of amplitude A, results in wavelet coefficients at the appropriate scale with magnitude A. In the older CWT, the magnitude of an oscillatory component in the wavelet coefficients depended on the scale.
We believe there are many other advantages of the new implementation in addition to the few I have mentioned. I would be very happy to discuss those and compare and contrast those at length with you.
Thank you again for your interest and for engaging in this way. As you said it is helpful for all.
Dear Wayne Thank you for your reply, we always learn something from it. The wavelet area is quite demanding in many ways and these discussions always add something to learn.
I would like to comment on your reply. I disagree that users are "confused by having to specify scales". A find the scale concept very easy to grasp, basically is the inverse of the frequency multiplied by some constant dependent on the wavelet type. I find it more complex, having to select at least two variables- 'VoicesPerOctave','NumOctaves' to be able to lock the transform to my frequency band of interest, be it realistic or unrealistic, as long as the Nyquist theorem is not violated.
I sent messages to various dsp experts and matlab wavelet users I know, asking them what 'VoicesPerOctave' would mean in the continuous wavelet context and nobody knew what to say. Moreover looking to the mathworks cwt online help about these two parameters, no explanation is present besides the defaults etc. Also no examples. Most of the provided examples just use the new cwt with two inputs, so the defaults are applied, and that is not illustrative. I gather that the scal2freq function is not important anymore in this new view.
One of the attractive features of the continuous wavelet transform it is its redundancy and ability to get the transform for any desired frequency or frequency band, to be able to obtain for instance, the energy time marginals in a given frequency band of indeed a single frequency/scale. I don't think the frequency/scale in the cwt has to be logarithmic, such as should be for the dwt. I would think that cwt redundancy allows us to obtain the transform in any scale/frequency within the Nyquist range. And in many time-scale representations in the medical field (bio-signal processing) it is highly desirable to have the frequency axis running linearly instead of logarithmically. And I would suppose you can do that with the cwt.
Nevertheless, from what I have read in the TMW site about the new cwt function I find it a new toolbox function with some new very interesting features, albeit reduced (or none) help for the Name-Value Pair Arguments which are crucial for developers that want to migrate from the old cwt to the new version.
One thing that bothers me the most is the fact that the new function has been named has the old one with explicit recommendation not to use the old one. Why not keep both (with different naming). Is mathworks trying to steer users away from the old cwt? Actually much of this discussion would be pointless if both functions would be kept with different names.
I know these things are quite subjective sometimes. But the concept of period (T) or frequency (F=1/T) of a periodic waveform is basic in the calculus syllabus. Although in the wavelet context things are not exactly the same as this, one may loosely associate the scale to the duration of the wavelet.