Re: compatibility of cov - past discussions and how to interpret for current bugfix?

[Nicholas Jankowski]

On Wed, Jan 18, 2017 at 11:13 AM, John W. Eaton <address@hidden> wrote:
> On 01/17/2017 12:32 PM, Nicholas Jankowski wrote:
>>
> If we were to change the default behavior, then how should we make the
> transition?  Do we need a warning or error to alert users that code that
> previously worked in Octave will be wrong?  If so, how do we know which
> behavior was desired?  Or do we just warn always, for the case that
> currently behaves differently in Octave and Matlab?
>


I honestly haven't looked at the actual calculation performed by cov,
mainly just looking at handling special cases for empty's and nan's
either at the front or backend. For those, I think compatibility is
easy enough. shape of output generally follows shape of numerical
output.

I generally prefer more compatibility.

According to that old thread:
"octave's cov(x, y) function is equivalent to the nan package's
covm(x, y, "D") function."

If that's still the case, a doc note and maybe a warning for the first
few versions that 'core cov has reverted to matlab compatible output',
if you want the old behavior use covm(x,y,"D")'  could suffice?

If it deviates from cov in other languages (python, etc.) that could
be worth a persistent warning.

And you probably saw it, but for everyone else, I did append my
previous comments to the bug report with a linkback to this
discussion. apologies if things bifurcate.
(https://savannah.gnu.org/bugs/?48690#comment18)