[BUG] - Technical Audit: Time Frequency edits

[elybrand]

This PR addresses the concerns raised in issue #193 for the time frequency analysis submodule, as well as the semantic issue raised in issue #196. Specifically,

1. compute_wavelet_transform now has norm as a kwarg to specify what normalization to use. It defaults to sss, or the L2 norm. Moreover, the output has been transposed so that frequency is plotted on the y-axis, and time on the x-axis. This matches convention for wavelet transforms in other packages.

2. Update the test for compute_wavelet_transform to average across the appropriate axis.

3. We now wrap the instantaneous phase vector using np.unwrap inside the call of freq_by_time.

4. Update the docstring for robust_hilbert to reflect that the return value is the analytic signal, not the hilbert transform.

[ryanhammonds]

This looks good to me! For you second point though, it doesn't look like the test for compute_wavelet_transform was changed. I can push tests updates after Tom reviews.

[TomDonoghue]

Okay, I had a look and reviewed the changes.

I've made a commit - to fix / update one thing. The update for freq_by_time had an issue in which it didn't deal with possibility of nan's coming out of phase_by_time, which happens when filter edges are removed. This means in that case, the output is all nan's, including in our online example.

I have edited freq_by_time to do nan-handling in our standard way. I also added some more comments, partly as I figured out the function as I went. @elybrand - can you check that my latest commit looks good to you?

As well as checking the code, here's a sanity check: the old & new version applied to our documentation example. The new version changes the 'frequency slips'. Is this what you would expect the updates to do, and does this look good to you?

OLD:

NEW:

If my updates look good to you Eric, and all this makes sense, then I think this is good to go, and can be merged.

[elybrand]

@TomDonoghue great catch with the nan's. Your commits look good to me. I'm not worried about the disappearance of the frequency "slips". Calling np.unwrap before differentiating makes things a smidge more stable, but ultimately the current way of differentiating phase is numerically unstable for general signals. I didn't make too much of a fuss about it because numerical differentiation is pretty challenging to do in a stable manner in general contexts. For the use cases of neurodsp, it's not worth trying to optimize here and it seems to be good enough.

[TomDonoghue]

@elybrand - sounds good! With the example, I mostly wanted to check how it changed makes sense and isn't surprising to you (as in, nothing weird happened!). I trust your judgement on numerical stability, and agree that within the use cases / standards here, this is general practice and reasonable!

Merging this one in!