[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
R: autocov and autocor
From: |
Marco Atzeri |
Subject: |
R: autocov and autocor |
Date: |
Thu, 28 Oct 2010 10:24:05 +0100 (BST) |
--- Gio 28/10/10, John W. Eaton ha scritto:
> Would someone with some signal
> processing expertise please take a look
> at the following bug report and comment on the proposed
> changes?
>
> https://savannah.gnu.org/bugs/?31474
>
> A google search shows that there have been a few other
> reports over
> the years, but I'm surprised that there have not been more
> since these
> functions have been in Octave for a dozen years and have
> not had any
> changes that affect the numerical results. So I'm
> wondering if there
> is some other definition of autocor and autocov that
> matches the
> Octave functions.
I am not a signal processing expert, I just studied
this staff long time ago at university, however
comparing
http://en.wikipedia.org/wiki/Autocorrelation
http://www.mathworks.com/help/toolbox/signal/xcorr.html
I see that the Octave autocov use the normalized approach;
while autocorr is just a scaled autocov and it looks wrong.
While Matlab xcorr use the not normalized approach.
I guess the best solution is to clarify in the
documentation how we are calculating autocor and autocov,
and eventually add also the xcorr.
However from Matlab documentation,
xcorr(x,y) produce a vector with length = length(x)+length(y)-1
so with
a =
0 0 1 1 0 0
xcorr(a) output should be long 11
like our convolution:
conv(a,a)
ans =
0 0 0 0 1 2 1 0 0 0 0
could someone with matlab verify the output of xcorr(a) ?
>
> Also, these functions are not in Matlab. Instead, the
> Matlab signal
> processing toolbox has xcorr and xcov functions, which I
> believe do
> the job that the person who reported the bug expects.
> These functions
> are also in the Octave Forge signal package. So maybe
> we should
> deprecate the autocov and autocor functions from Octave and
> eventually
> remove them? Or should they be fixed as
> proposed? If they are, is it
> possible that there is working code somewhere that depends
> on the
> current behavior (i.e., there is an alternate useful
> definition of
> autocor and autocov that Octave's current functions
> implement)?
>
> I'm appending diffs below.
>
> jwe
>
Marco