is Matlab (R2009b) ignoring the transpose operator in “mldivide”?

I am trying to solve the linear system of equations A'*x = B using "mldivide" or the backslash operator in the form:

x_transp = A'\b;

"A" is a square sparse matrix with real (non-complex) numbers and that is all I know about it. The problem is that the transpose has no effect at all in the example I indicate below, so the result of the previous line of code is the same than:

x = A\b;

So, x = x_transp, but this is clearly incorrect (A ≠ A'). As a summary of the tests I have performed:

• A ≠ A'; (OK)
• A'\b = A\b; (Wrong results)
• A'\b ≠ A.'\b; (A.'\b is OK)
• C = A'; C\b = A.'\b; (OK)
• transpose(A)\b = ctranspose(A)\b = A.'\b;(OK)
• A' = ctranspose(A) = A.' = tranpose(A); (OK)

This behavior occurs in Matlab version 7.9.0 (R2009b) but it does not happen in 7.12 (R2011a). This behavior does not occur with some other simple examples of "A" and "b". There is no warning or error message. Example matrices that make this behavior arise are:

 A= [0.01   -0.495  0   0   0   0   0   0   0   0
        0        1  0   0   0   0   0   0   0   0
        0        0  1   0   0   0   0   0   0   0
        0        0  0   1   0   0   0   0   0   0
        0   -0.495  0   0   1   0   0   0   0   0
        0        0  0   0   0   1   0   0   0   0
        0        0  0   0   0   0   1   0   0   0
        0        0  0   0   0   0   0   1   0   0
        0        0  0   0   0   0   0   0   1   0
        0        0  0   0   0   0   0   0   0   1];

 b =   [8
        4
        0
        0
        0
        0
        0
        0
        0
        0];

Why do I obtain A'\b = A\b in Matlab (R2009b), if A ≠ A'? Is it some kind of precision issue? Is because my linear system of equations is "unstable" as suggested in this other question?

Thank you for your time.

Answer 1

[Sean de Wolski]

I think you're seeing the same bug as described here:

http://www.mathworks.com/matlabcentral/newsreader/view_thread/267273

Answer 2

[John D'Errico]

I get different results with R2014a, so it is very possibly a release issue with the interpreter.

You might check if

x = (A')\b;

has the same problem too. You might even be more forceful if that still has a problem, breaking it into two lines to stop the interpreter from screwing up.

Ap = A';
x = Ap\b;

Even better, why not upgrade anyway, since R2009 is OLD? They have done much since then. As well, IF this is an issue, you won't get a patch for the old release, so an upgrade is smart.

[Mario Lopez]

Yes, using parenthesis or brackets leads to the same wrong behavior. Upgrading is not an option (I have no control over the software of the PC). Breaking it into two lines works and it is not a big deal, but I just wanted to raise the question to the community because: 1) I did not know if it was my fault (because of bad conditioning of the system) and 2) if you are unaware of this behavior, you may have a hard time trying to debug your code (nothing is apparently wrong and there is no bad practice here).

[John D'Errico]

Yeah, I just always make sure I am using the newest release. That has the result that I never see the old bugs, just the newest ones. :)

If breaking it into two lines does fix it, then it is surely an interpreter problem.

[James Tursa]

Tested all versions R2006b - R2013a (except R2007b) on WinXP 32-bit. Problem only appears in R2009b. So, apparently, this was a bug introduced in R2009b and quickly fixed in R2010a. The problem only manifests itself if A is full ... when A is sparse the correct result is obtained. The problem happens even when "feature accel off" is used. My conclusion is the same as John's ... likely a parser optimization bug that was subsequently fixed.