Debugging all day

Today was incredibly concentrated on the strange behaviors of CMP in MPTK.
We found some errors are due to quantization, and others to energy approximation (to avoid lots of high dimension inner products).
But none of these had that much of an effect.
We tried real MDCT atoms instead of complex Gabor atoms; and that seemed to make things worse.
We tried to update all the inner products at each step,
but that didn’t help.
We pulled out the big guns and ran step by step through the code with Eclipse and then XCode, trying to access
shards of memory containing the frequencies of atoms impenetrably type cast.
No matter what we did, it seemed that CMP was making poor atom choices during some of its refinement cycles. This is theoretically unacceptable. It should never ever ever increase the residual energy by an atom replacement.

Below you see something by CMPTK that looks reasonable, as long as we ignore the messages that some refinements are increasing energy. I am using the same test signals as yesterday. And the dictionary is made of complex Gabor atoms with scales = [4 8 16 32 64 128 256 512] and hops = [2 2 4 8 16 32 64 128], respectively.

I ran some MATLAB simulations for three of these signals, using nearly the same dictionary (I included the Dirac basis) the results of which are shown below. Clearly, not only does my implementation produce much better results, it does so in 1000 times the time of CMPTK. (When I include the Dirac basis in CMPTK, things do not look good at all.)

I just had a thought.
My MDCT dictionary I used a bit earlier had Gaussian window shapes,
and strange shifts and frequency resolutions.
When I take those things out, and give the atoms Kaiser-Bessel windows with parameter 5, and have atoms with scales = [4 8 16 32 64 128 256 512],
I get no energy increase errors!
The residual decays are below. So maybe it has something to do with the windowshape and complex atoms.

Below are the decays produced by using the Gaussian shaped MDCT atoms with scales = [4 8 16 32 64 128 256 512] and hops = [2 2 4 8 16 32 64 128]. Clearly, something very bad is happening there.

All these things tell me the real problem(s) is(are) very subtle. CMP is such a simple algorithm to implement; MPTK must be doing something that I don’t know about.
In the interest of time, I think I will assume the algorithm CMPTK is approximately correct (or we can just call it by a new name, CMP-like), and use either the dictionary producing the first graph above, or the MDCT with Kaiser-Bessel windows.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s