Is it fair to say that the result signal, even after cutting out the wings, will still be "contaminated" by the zero padding for at least another half kernel length, which would be when it start having a pure and clean signal/kernel convolution? Does it make sense?
It is certainly the case that edges are always difficult to interpret from any kind of filtering. When possible, it's best to have extra time series before and after the period of interest, so that you can ignore those edges.
I'm wondering why not aligning the center of the kernel with the edge of the signal (still need zero-padding, but less extra zeros) so that we can get the result with exact same length as the original signal, thus no need to cut off the "wings"?
If you are implementing convolution manually in the time domain using for-loops, then yes, that's convenient. But the formal procedure is done to match the implementation in the frequency domain, which is much faster.
Wouldn't the convolution it be a better representation of the signal, if you could wrap around the edges of the signal? I.e. you'd start the kernel's mid point at the start of the signal and take the left half of the kernel from the right side of the signal and if the kernel exceeds the right bounds, take the data from the start of the signal? This way your convolution would have the same length as the signal, but operate only on the signal's data and not sneak in zeroes that have no meaning and pollute the results.
Yes, that's called "circular convolution"; what I explain here is "linear convolution." Both methods produce edge effects that should not be interpreted.
@@mikexcohen1 teacher. I want to make sure if if my thoughts are correct. The edge effect will occur when we use 'Convolution Theory' to obtain the result of the convolution between two signals. This is because 'Convolution Theory' uses FFT. If the max frequency of the two signals exceeds the Nyquist Frequency, aliasing will occur. This is why it's called the "edge effect", right? Sorry I'm not native English speaker, if something's confusing, please correct me.
If the kernel is a morlet wavelet (formed by combining a constant sine wave and gaussian) and symetrical around the mid point, flipping the kernel is not necessary, is that accurate? Thanks for the great video
Kindof, but be careful with the descriptions: The kernel always needs to be flipped, but if the kernel is symmetric, then flipping has no effect. (Also, sine is an odd function and thus is asymmetric; cosine is symmetric about zero.)
Mike X Cohen - the unsung hero of our age
Aww, now you make me blush ;)
Super clear explanation, very intuitive. Thank you.
You're welcome!
really very pedagogical. Thank you
You are such a good teacher :)
aww, thanks!
Is there a way to buy your Analyzing Neural Time Series Data book on credit for monthly payments?
Hi Jesus. Find my email address (it's on my CV) and send me an email about this.
Is it fair to say that the result signal, even after cutting out the wings, will still be "contaminated" by the zero padding for at least another half kernel length, which would be when it start having a pure and clean signal/kernel convolution? Does it make sense?
It is certainly the case that edges are always difficult to interpret from any kind of filtering. When possible, it's best to have extra time series before and after the period of interest, so that you can ignore those edges.
I'm wondering why not aligning the center of the kernel with the edge of the signal (still need zero-padding, but less extra zeros) so that we can get the result with exact same length as the original signal, thus no need to cut off the "wings"?
If you are implementing convolution manually in the time domain using for-loops, then yes, that's convenient. But the formal procedure is done to match the implementation in the frequency domain, which is much faster.
Wings of convolution: a good band name
I'll be the back-up kazoo player.
Wouldn't the convolution it be a better representation of the signal, if you could wrap around the edges of the signal?
I.e. you'd start the kernel's mid point at the start of the signal and take the left half of the kernel from the right side of the signal and if the kernel exceeds the right bounds, take the data from the start of the signal? This way your convolution would have the same length as the signal, but operate only on the signal's data and not sneak in zeroes that have no meaning and pollute the results.
Yes, that's called "circular convolution"; what I explain here is "linear convolution." Both methods produce edge effects that should not be interpreted.
@@mikexcohen1 teacher. I want to make sure if if my thoughts are correct.
The edge effect will occur when we use 'Convolution Theory' to obtain the result of the convolution between two signals.
This is because 'Convolution Theory' uses FFT. If the max frequency of the two signals exceeds the Nyquist Frequency, aliasing will occur. This is why it's called the "edge effect", right?
Sorry I'm not native English speaker, if something's confusing, please correct me.
you lost me at God's perspective, now I'm flipping (out) instead of the kernel :D But I am very thankful for all the videos and the ANTS book
Nice.
Richard Hamming's Digital Filter explains this god's perspective in a different way, worth checking imho.
If the kernel is a morlet wavelet (formed by combining a constant sine wave and gaussian) and symetrical around the mid point, flipping the kernel is not necessary, is that accurate? Thanks for the great video
Kindof, but be careful with the descriptions: The kernel always needs to be flipped, but if the kernel is symmetric, then flipping has no effect. (Also, sine is an odd function and thus is asymmetric; cosine is symmetric about zero.)
How do you decide what sort of kernel to use?
That's application-specific. But the procedure of convolution doesn't depend on the shape or length of the kernel.
congratulations for explanation, was very enlightening for me
Nice to hear. I made this video just for you, Renan :D
Excellent explanations
Glad you liked it!
This is good stuff. Good Job!
Very nice explanation
This video is super helpful, thank you so much!
Awesome video! Thank you so much!