help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hilbert transform


From: Sergei Steshenko
Subject: Re: Hilbert transform
Date: Sat, 7 Jul 2012 08:10:03 -0700 (PDT)




----- Original Message -----
> From: John B. Thoo <address@hidden>
> To: Sergei Steshenko <address@hidden>
> Cc: Ben Abbott <address@hidden>; "address@hidden" <address@hidden>
> Sent: Saturday, July 7, 2012 5:01 PM
> Subject: Re: Hilbert transform
> 
> 
> On Jul 6, 2012, at 3:34 PM, Sergei Steshenko wrote:
> 
>>  ----- Original Message -----
>>>  From: Ben Abbott <address@hidden>
>>>  To: Sergei Steshenko <address@hidden>
>>>  Cc: "address@hidden" <address@hidden>
>>>  Sent: Friday, July 6, 2012 8:53 PM
>>>  Subject: Re: Hilbert transform
[snip]
> 
> Hi, everyone.  I'm sorry for joining late, and with no answers, but with a 
> question.
> 
> As Sergei pointed out, with  x0 = [-3,-1,1,3],  H(H(x0)) \neq -x0.  However, 
> with  y0 = [-3,-1,3,1],  indeed  H(H(y0)) = -y0.
> 
> 
> octave-3.2.3:13> y0 = [-3,-1,3,1]
> y0 =
> 
>   -3  -1   3   1
> 
> octave-3.2.3:14> y1 = imag (hilbert (y0))
> y1 =
> 
>    1  -3  -1   3
> 
> octave-3.2.3:15> imag (hilbert (y1)) + y0
> ans =
> 
>    0   0   0   0
> 
> octave-3.2.3:16> 
> 
> 
> Why the difference?
> 
> Btw, here is another routine for the Hilbert transform that avoids using 
> "imag".
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%% begin hilb.m %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> function out = hilb(in)
> % HILBERT computes real hilbert transform of real input
> % Has symbol -i sgn(k)
> lx = length (in);
> in = fft (in);
> in (1:(lx/2+1)) = -i*in (1:(lx/2+1)); 
> in (lx/2+2:lx) = i*in (lx/2+2:lx); 
> out = real (ifft(in));
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%% begin hilb.m %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> ---John.
> 

Hilbert transform can not be calculated exactly unless the integral can be 
calculated analytically.

So, some input signals are better and some input signals are worse.

For example, a widely publicized example is Hilbert transform of square wave. 
It _can_ be calculated analytically, and where the square wave has slopes, the 
transform value reaches +/-infinity.

I.e. if one tries to calculate it numerically, he/she is doomed to fail. 
Because, for example, _discrete_ Fourier transform is by definition a sum of 
_finite_ number of sine and cosine functions, so the sum is _finite_ - 
regardless of the issue of representing infinity in a digital computer.

So, when one calculates numerically on a digital computer 
Hilbert(Hilbert(foo)), _both_ transforms are approximate. Sometimes errors 
cancel out, sometimes not.

For gory details one can read 
https://ccrma.stanford.edu/~jos/sasp/Hilbert_Transform.html and click "Next" 
link at the lower left corner sufficient number of times.

And here: http://arxiv.org/pdf/0907.4176.pdf is an article giving examples of 
Hilbert transform errors in "simple English".

...

Ironically, with a lot of packages loaded in my Octave, 'hilb.m' is from 
'special matrix' in my case :). An approach needs to be found to avoid name 
collisions.


Regards,
  Sergei.



> 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]