[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.
>
- Re: Hilbert transform, (continued)
- Re: Hilbert transform, Sergei Steshenko, 2012/07/06
- Re: Hilbert transform, Ben Abbott, 2012/07/07
- Re: Hilbert transform, Sergei Steshenko, 2012/07/07
- Re: Hilbert transform, Ben Abbott, 2012/07/07
- Re: Hilbert transform, Sergei Steshenko, 2012/07/07
- Re: Hilbert transform, John B. Thoo, 2012/07/07
- Re: Hilbert transform, John B. Thoo, 2012/07/07
- Re: Hilbert transform,
Sergei Steshenko <=