Re: Behavior of mldivide in Octave relative to Matlab

[Marco Caliari]

Dear all,

> Consider this example:
>
> m = 10; n = 10000; A = ones(m,n)+1e-6*randn(m,n); b =
> ones(m,1)+1e-6*randn(m,1); norm(A\b)
>
> while Octave's minimum-norm values are around 3e-2, Matlab's results
> are 50-times larger.

On the other hand, Matlab's result is sparse, which could be a desirable 
feature.

> It shows that unlike in Octave, mldivide in Matlab is not invariant
> w.r.t. column permutation
> if there are multiple columns of the same norm - i.e. permuting
> columns of the matrix gets you different result than ermuting the
> solution vector. I bet that many Matlab users would be surprised by
> this behaviour.

This is a bigger issue, I agree with Jaroslav.

> >  Another issue is what is the result that is returned by Matlab and
> >  Octave for singular matrices. Consider a case like
> >
> >  A = [eps, 0, -eps; 0, eps, -eps; -eps, 0, 10]; x = A \ ones(3,1)
> >
> >  Octave falls back to using xGELSD to solve the matrix in this case
> >  whereas as Matlab returns the result based on LU factorization with a
> >  warning of its inaccuracy.

> This is again the intelligence vs. speed.

Yes, even if Matlab's result gives

> > norm(A*x-ones(3,1))
ans =
     0

whereas Octave gives

octave:10> norm(A*x-ones(3,1))
ans =  1.41421356237310e+00

(I know that a small residual does not mean a small error...).

> I'd suggest making it an option, and keep Octave's behavior the default.

I agree. Is it possible to define two built-in variables 
controlling the behaviour? This would make easy to change the behaviour of 
complex scripts.
Only a final note: the case m=50 and n=20000 works in Matlab's A\b whereas 
it fails in Matlab's [Q,R,E]=qr(A) (same problem of exhaustion of the 
memory as in Octave).

Best regards,

Marco