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

[John W. Eaton]

On 01/17/2017 12:32 PM, Nicholas Jankowski wrote:
> I was revisiting my patch for bug #48690 [1].  I initially thought cov
> to be the simplest since it only takes a 2d argument, but I missed the
> multiple argument aspect. trying to cover that, I just realized that
> tests I'm generating to try to maintain matlab compatibility may be
> running afoul of the previous decision for a planned
> non-compatibility.
>
> [...]
>
> So, summary: there seemed to be a consensus years ago to keep the
> incompatibility. with that in mind, what should target output look
> like for this 'compatibility' bugfix?

Even though people have always wanted to be able to run Matlab code in 
Octave without having to change it, I think compatibility had a somewhat 
lower priority in the past and that's what lead to the decision to be 
incompatible here.

But now I'm not sure that it is the best thing to do.

With the current situation, is it possible (or even likely) that an 
incompatible answer from cov could go unnoticed?

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?

jwe