Re: autocov and autocor

[Rik]

> 
> Subject:
> autocov and autocor
> From:
> "John W. Eaton" <address@hidden>
> Date:
> Thu, 28 Oct 2010 03:09:35 -0400
> To:
> octave maintainers mailing list <address@hidden>
> 
> To:
> octave maintainers mailing list <address@hidden>
> 
> 
> 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.
> 
> 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)?

John,

I'd done some checking, but hadn't consolidated everything in my mind to
write up.  The short answer is that there is very little definitional
certainty about how to calculate the cross-covariance (and hence the
special case of the autocovariance).  Although the bug poster was
*emphatic* about the correct way to do things, in fact, it varies between
academic fields and even when the same method is used there is a
normalization factor which varies.

To illustrate the ridiculousness of it all, Matlab, can calculate the
cross-covariance in 4 different manners
(http://www.mathworks.com/help/toolbox/signal/xcov.html).  For Matlab, the
default option, 'none', produces what the bug reporter expected.  Octave
uses the equivalent of the 'unbiased' option.  Octave is not wrong, just
different.

In this case, where there is no clear cut standard, my leaning is to follow
Matlab; at least we can all be wrong together.  Still, I think overall
these functions are too esoteric and should be removed from the core.  The
alternative would be to patch them up to be the equivalent of xcov and
xcorr and that seems like a lot of work; particularly, as the Octave-Forge
signal package already implements all the options for those two functions.

--Rik