octave-maintainers
[Top][All Lists]
Advanced

[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





      



reply via email to

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