Talk:Hilbert transform

From Wikipedia, the free encyclopedia

Contents 1 Introduction 2 Hat notation 3 MathWorld & Matlab 4 Discrete HT 5 Practical implementations 6 Discrete HT again 7 Why named after David Hilbert? 8 (h*s)(t) or h(t)*s(t) ?

[edit] Introduction

It is not true that the integral defining the fourier transform of h diverges. It is not even possible to consider h as a tempered distribution and thereby get the result. On the other it is possible to define a tempered distribution out of h by cutting off near 0 and taking a limit. But this is closely related to the fact we need a principle value. And it is correct to say the as an operator is the multiplier operator with multiplier . We may want to find a way to rephrase this part.

[edit] Hat notation

The notation should be removed. It is not standard across mathematics and signal processing. And conflicts with the notation more standard notation for the fourier transform. Seeing how the Hilbert transform almost always involves a discussion of the Fourier transform I believe this to be a poor choice of notation.

Please sign your entries with "~~~~".

Regarding your suggestion, the argument that it is "not standard across mathematics and signal processing" is not a strong argument, since very few notations of any kind enjoy that unique status. The hat notation is quite common in signal processing, at least. It's no accident that it appears here. Furthermore, I for one have seen quite a few Fourier transforms, and I don't recall any that used the hat notation. I am not saying it doesn't exist, but it is certainly far from being the standard you claim it to be. --Bob K 05:21, 14 July 2006 (UTC)

Regarding my suggestion. Here are a list of references I might mention that use a hat to denote the Fourier transform.
M. Pinsky "Introduction to Fourier Analysis and wavelets"
B. Hubbard "The world according to wavelets"
C. Blatter "Wavelets: A primer"
W. Rudin "Real and Complex Analysis"
Conte and de Boor "Elementary Numerical Analysis An algorithmic Approach"
E. Stien and R. Shakarchi "Fourier Analysis: An introduction"
And the list continues, see also papers published by R. and C. Fefferman, T. Tao, E. Stein, etc.
Now I don't doubt that there is plenty of evidence for the Hilbert Transform. But the notation definitely conflicts, and we can agree that H(f) is a reasonable way to denote it. We can definitely add comments about different notations in different fields.

Thenub314 20:24, 17 July 2006 (UTC)

That's a good list. (Thanks.) It's not an encyclopedia's job to suppress any of the common notations. On the contrary, its job is to try to describe the real world in all its ugly complexity and inconsistency. The really hard part, of course, is trying to maximize its own internal consistency at the same time. Maybe some day each reader will have a "profile", of his own choosing... and articles will be automatically translated through that profile to create the view he wants to see. --Bob K 03:41, 18 July 2006 (UTC)

[edit] MathWorld & Matlab

Math world has the plus and minus reversed in

The way it is now coincides with the MATLAB function when plotted, and also coincides with the diagram in my book (going from −∞ to +∞ during a positive side of the square wave), and the equation in my book for a pulse of width τ delayed by τ/2, so I'm leaving it this way. - Omegatron July 2, 2005 17:03 (UTC)

Very strange. In the mathworld we see that hilbert transform is the convolution with -1/t*pi function, not 1/t*pi. But the table with hilbert transform is nearly the same. Somebody just have written it down without thinking.

I will correct it as soon as I create an account.

--83.25.155.136 16:41, 18 September 2005 (UTC)

[edit] Discrete HT

I'm trying to figure out what is going on with the discrete HT. That section now says that there is an ideal discrete HT, so and so, but this operation cannot be realized in the signal domain. Then, it presents a filter which seems to do the job, derived from the DFT. This seems contradictory. --KYN 21:41, 10 November 2005 (UTC)

I think it's not contradictory, because his is non-realizable, as written. But maybe what you are saying is that n does not go to ± inf, because it is just a DFT. Therefore it can be made realizable, with sufficient delay. And the "ideal" filter would not have that characteristic. Is that the problem? --Bob K 09:30, 7 December 2005 (UTC)

I guess what is said is that from the ideal filter in the Z-domain it is not possible to derive a filter in the signal domain by means of the inverse Z-transform? Maybe then it is better not to involve the Z-domain in the discussion? Is it possible to present it in the following way? First define a "Hilbert filter" in the Fourier domain as

H(u)= -i for even integer < u < odd integer
H(u)= +i for odd integer < u < even integer

Please clarify this definition, if you can. I'm not getting it yet. --Bob K 20:36, 7 December 2005 (UTC)

Hopefully it's all OBE now, since I just re-wrote that section of the article. --Bob K 01:52, 8 December 2005 (UTC)

ie an oscillating square wave. The inverse DFT of this function will be precisely the discrete filter presented in the article. Then maybe continue to say that there is an ideal version of this filter in the Z-domain, with the given expression, but there is no formal relation to the discrete filter via the Z-transform or its inverse.

KYN 21:41, 10 November 2005 (UTC)

About the discrete algorithm I read a trick : it work better with a 0 for the first point. So, thanks to the fast fourier transform the algorithm may be written

X(f) = FFT( x(t) )
if f == 0 : H(f) := 0
if f > 0 : H(f) := - i * X(f)
if f < 0 : H(f) := +i * X(f)
h(t) = iFFT( H(f) )

but with almost all the implementation of the FFT the spectrum unfolding (the negative part is stored after the positive one) imply one more 0 as you can see in this dirting matlab script :

len = length(wave_in);
fft_in = fft(wave_in);
fft_quad = [ 0 ; - 1i * fft_in(2 : len / 2); 0 ; 1i * fft_in(len / 2 + 2 :len)];
wave_out = real(ifft(fft_quad));

btw very useful to get the envelope ^^ enveloppe(t) = sqrt ( x(t)^2 * h(t)^2 ) for all t.

[edit] Practical implementations

Forgor to write something in the "comment" but I noticed the comment about the discrete ideal filter being non-causal, and realized that this is a general propery of the HT, both continuous and discrete. I tried to formulate something about this.

[edit] Discrete HT again

I don't really have an experience with the DHT and therefore I must ask the following questions, some of which hopefully can work their way into the article to make it more understandable.

• Exactly how is the DHT related to the continuous HT? I can see that there are similarities, but not that the DHT follows straightforward from the CHT. The CHT is defined as it is simply because it make sense in a number of applications. I guess that it can be shown that the DHT also has this property. Examples?

>>>Probably its main use is to convert real-valued discrete signals into the analytic representation. --Bob K 06:21, 4 January 2006 (UTC)

• I understand that there is a problem in defining the discrete equivalent of the filter h(t) since it would have to be infinite at n=0. OK, let's set h[n]=0. But why should also all other even samples of h[n] vanish? Why is not a valid approximation to define h[n]=1/(pi t) for n not 0 and h[0]=0? For example, the CHT of a bandlimited signal is again bandlimited. Consequently, the computation of the CHT could be made in terms of an operation on a discrete version of the signal, if appropriately sampled.

>>>But the discrete version of the signal is no longer band-limited. The DTFT is periodically extended (to infinity). A CHT would shift all the positive freq components by -90 deg (and all the negative freq components by +90 deg). But (as the article states) what's actually needed is to shift (0,π] by -90, (π,2π] by +90, (2π,3π] by -90, etc. The derivation of the corresponding h[n] sequence is indicated at slide 21. Note that the function takes on alternating 1,0,1,0,1,0,... values for odd and even values of n. --Bob K 06:21, 4 January 2006 (UTC)

• Would the corresponding operation be a discrete convolution by the h[n]-filter as it is defined in this section?

>>>Yes, except for the fact that it has to be approximated by something with finite duration. --Bob K 06:21, 4 January 2006 (UTC)

• If so, this fact is worth mentioning since it makes the definition of h[n] much clearer. If not, I am lost.

• What exactly does "usual filter design tradeoffs" refer to? I can guess, but some readers will not understand this. Either be a little more specific or expand the subject on a page of its own.

>>>Filter-order vs. frequency-response and latency is always a tradeoff. Another issue is truncation vs. numerous methods of gradual tapering off to zero-valued coefficients. These topics are of general enough interest that they should be treated elsewhere and only referenced here. --Bob K 06:21, 4 January 2006 (UTC)

• There is a filter design article. Are the tradeoffs described sufficiently well there so that it is reasonable to use a link?

>>>Sorry, I haven't investigated that myself. --Bob K 06:21, 4 January 2006 (UTC)

>>>I just took a peek, and the treatment is indeed brief. But filter-design is a well-studied and dauntingly large subject to cover in detail. And excellent tools are widely available so that most practitioners don't really have to understand all the issues. So I doubt that wikipedia will take on that challenge anytime soon, if ever. All most readers will need to know is that there are tradeoffs, so they should seek the help of a decent tool if they want to do a good job. It's like telling people that their car needs its oil changed, rather than detailing how to change the oil in every kind of car. I think that is valid. --Bob K 06:55, 4 January 2006 (UTC)

• What exactly does "DFT approximation of it" mean. "it" seems to refer to h[n]. It what sense are we dealing with an approximation? Of what?

>>>Perhaps a second reading would help. But here is the short version: Instead of the convolution, people often do a DFT, modify the coefficients in the obvious way, and then do an inverse DFT. That is equivalent to a circular convolution with the approximation shown in the article. --Bob K 06:21, 4 January 2006 (UTC)

• The operation which is referred to as "fast convolution" is not really described to a sufficient detail to make it understandable. I don't see it before me how this operation is implemented in practice. What is the relation between fast convolution and cyclic convolution? Maybe fast convolution needs a page of its own, rather than to have to be described in detail in this article?

>>>Yes. Due to the efficiency possible with the FFT algorithm, the DFT/IDFT approach is often faster than simple convolution, even when actual multiplications (by other than ±1 and 0) are required. Again, that topic is of sufficiently general interest that this is not the right place for it. And again, I have not searched for the reference. If you have looked already, then you might try looking for the names overlap-save and overlap-add, which describe specific techniques for piecing together the outputs of block-processing, an essential part of the FFT approach with streaming data. --Bob K 06:21, 4 January 2006 (UTC)

--KYN 23:51, 3 January 2006 (UTC)

I have summarized the first part of this discussion in the intro of the DHT section. Please have a look to see if it came out the right way. --KYN 13:48, 4 January 2006 (UTC)

Looks fine. --Bob K 20:06, 4 January 2006 (UTC)

Now, I am still a bit concerned about the rest of that section. To me, it appears to discuss rather general principles of filter design, how to truncate and shift an infinitly extended filter, and how to implement the convolution operation in the frequency domain instead of the signal domain. The first part of this is more or less identical to the discussion for the continuous HT, isn't it? The latter, is something that relates to any discrete convolution operation, not just DHT. In that case, it could be moved to somewhere where the relation between signal domain convolution can be compared to "fast convolution" on a more general level. --KYN 13:48, 4 January 2006 (UTC)

The article does contain a link to circular convolution, which goes into more depth about fast convolution. But normally, one uses design techniques to choose a finite filter order. Then one transforms that design into the frequency domain. For some reason, when it comes to the DHT, there seems to be a propensity to skip that step, and just use the idealized , which makes circular convolution unavoidable. Seems to me that it's like using an ideal rectangle for a lowpass filter, which nobody does. Since this seems to be endemic to the DHT, I thought it was worth a little space at the expense of some redundancy. --Bob K 23:28, 4 January 2006 (UTC)

Ok, I will look at the fast convolution section in the circular convolution articles which you pointed out, and try to make sense of all this. For some reason this page does not appear when I try to search the wikipedia for "fast convolution". Any idea why?--KYN 00:42, 5 January 2006 (UTC)

Sorry, no. It fails for me also. --Bob K 01:47, 5 January 2006 (UTC)

I just tried it again. It still failed, but now it knows something is wrong, and it recommends I use Google or Yahoo, with the "Wikipedia" option selected. Those work just fine. --Bob K 02:34, 24 April 2006 (UTC)

[edit] Why named after David Hilbert?

Did he develop and define this concept? Whaa? 21:31, 23 April 2006 (UTC)

Excellent question. I don't exactly know myself, I suspect that either it came up during his study of integral equations. But none of the biographies I have read explain exactly what he was thinking about in this respect. As far as the history of the Hilbert transform, the first real theorems I know that were proven about it go back to M. Riesz. It is also the prototypical example of a singular integral operator, and the Hilbert transform was what motivated Zygmund to study such opertators. 75.3.32.251 12:14, 18 July 2006 (UTC)

[edit] (h*s)(t) or h(t)*s(t) ?

This has undoubtedly been discussed somewhere else, so here we go again. If it comes to a vote, I prefer this convention:

to this one:

--Bob K 14:50, 17 October 2006 (UTC)

If it comes to a vote I prefer

Thenub314 16:15, 17 October 2006 (UTC)

I agree with Bob K. First Harmonic 19:39, 17 October 2006 (UTC)

One thought on the subject is that the current notation is consistant with the Convolution article. Thenub314 23:36, 18 October 2006 (UTC)

Clearly, both notations are common in the literature, and on WP. The notation that I prefer is commonly used in signal processing and communication systems engineering, wheras the notation preferred by Thenub314 is more common (I think) in mathematics. So you could argue that either notation (or both) is acceptable. That being said, it comes down to a question of taste and familiarity. I prefer the one notation over the other not only because it is what I am familiar with, but also because I think it is easier to understand, clearly represents what is what, and is less ambiguous than the other. First Harmonic 16:01, 26 October 2006 (UTC)