concatenation - What is wrong with this MATLAB code?

Question

I am trying to do following in MATLAB,

global a b c d e f g h l;
A=[1 3;3 2];
B=[a 0;0 b];
C=[d 0;e f];
Ctranspose=transpose(C);
D=[sqrt(d) 0;0 sqrt(f)];
E=Ctranspose/D;
Etranspose=transpose(E);
K=A+E;
M=E*D*Etranspose;

for a=1:10
  for b=1:10
    if  K==M
      print(a);
      print(b);
      print(d);
      print(e);
      print(f);
    end
  end
end

I get following errors:

a)

Error using  + 
Matrix dimensions must agree.

Error in trial (line 6)
K=A+B

b)

Error using vertcat
CAT arguments dimensions are not consistent.

Error in trial (line 5)
C=[d 0;e f];

What is wrong here?

(Kindly note that I am new to MATLAB)

Thanks

Answer 1

Ouch! OUCH! Let me just jump right in there and interrupt you before you continue down this path!

I know you're not a programmer, but at some point in life (apparently, this is yours!), you have to face the facts and become one, however momentarily. So know that programming is not really a science, it's an art, a craftsmanship if you will, and one that is all too easy to get wrong. Know also that there have been millions upon millions of programmers before you, who paved the way for you and found out which methods work best, and which methods lead to certain disaster.

I will describe six of these "roads-to-certain-doom" that are present in your code.

First on the list, is the use of global. DON'T USE GLOBAL VARIABLES!! Sure, they are all-right for small, simple things, but the better, much more manageable, more durable, robust, much less error-prone way of passing data around is to do it manually. As a rule of thumb, create all top-level functions with as little dependencies to other functions/variables as possible. This is because global variables create a tight coupling between a program's state and a function's output, which makes reproducing any errors hard, if not impossible, and debugging (which is actually what any programmer spends most of his/her time on) a complete nightmare. Also, any function other than the one running can change them, so that

function testMe
    global a;
    a = 5*rand;
    someFunction;
    b = 4*a; % ERROR! or...will it? 

function someFunction
    global a;
    a = a/5;
    if a < 0.5
        someOtherFunction; end

function someOtherFunction;
    global a;
    a = {'my string'};  

will sometimes work, and sometimes fail. An example of something worse that can happen:

function testMe
    global a, b;
    a = 5; b = 6;
    result = someCalculation;
    result = a*b*result;


function someFunction
    global a;
    a = sin(pi/rand); % INTENTIONAL

    % do LOTS of stuff here

    for a = 1:10 % OOPS! unintentional use of variable name
        % do stuff
        if (some weird condition)
            break; end
    end

There will be no error, no warning, nothing, but your results will still be garbage. And as your functions grow larger (and they WILL, usually), this error gets harder and harder and harder to find. It's not uncommon to spend a good few days on finding this sort of mistake.

In your code, you also change the global variables a and b inside the loops. This means that any function/script that uses a and b, that gets called after this one completes, will see a=10 and b=10. Now suppose you call a function inside those loops, that changes the value of a. What will the value of a be on the next iteration of the a-loop? Suppose also you get erroneous results. How would you go about finding that error?

Code like this is usually called "spaghetti code", for obvious reasons. Perhaps it will work, and is easy to code, but in the end it will always slow you down tremendously (not to mention the one who inherits your code).

A much better approach that prevents most of this is to collect data in larger containers, and explicitly pass them around. Say we use a struct for the data a-l:

data = struct(...
    'a', a,...
    'b', b,...
    'c', c,...
    'd', d,...
    'e', e,...
    'f', f,...
    'g', g,...
    'h', h,...
    'l', l);

So that you can say

result = myFunction(data);

Accessing data inside myFunction goes like this: data.a to get the value for a, or data.f for the value of f, etc. Saying data.k = 5; in myFunction will not change the result, or the original data passed to the function -- you have broken the tight coupling and prevented all the aforementioned problems.

Type help struct or help cell in the Matlab command window to learn about these sorts of generic containers.

Second on the list is using the variable name l. It's somewhat silly, and I can be short about this: don't do that :) Contrary to what most people (and even some programmers) believe, you write a line of code only once, but you read it hundreds, if not thousands of times. The best practice is to make the reading as easy as possible, not the writing. The l just looks like the 1, doesn't it? The bug k=1 vs k=l is simply harder to spot than k=m vs k=1.

Third on the list is the keyword transpose. It's kinda verbose, isn't it? In math, you would use A^T, which is much easier on the eyes than writing the full definition all of the time:

B = { A_ij ? A_ji ? i < m ? j < n

you normally just say B = A^T. Same in Matlab. The transpose of a matrix can be accomplished like so:

Actrans = A' ; % conjugate transpose
Atrans  = A.'; % regular transpose

which reduces your code to the much less verbose

A = [1 3;3 2];
B = [a 0;0 b];
C = [d 0;e f];    
D = [sqrt(d) 0;0 sqrt(f)];
E = C.'/D;    
K = A+E;
M = E*D*E.';

Fourth on the list is the equality K==M. As it stands here, K and M are matrices. The expression K==M is evaluated element-wise, for reasons that will become obvious later in your programming career :) This means that K==M will be again a matrix, the same size as K and M, containing 0 if corresponding elements in K and M are not equal, and 1 if these elements are equal. So, what will an if-statement do with such a matrix? In Matlab, it will be true whenever the first element is true (in my opinion, it should throw an error, but oh well).

This is obviously not what you want. what I think you want is that all elements in both matrices are equal. It's best you use this:

if all( abs(K(:)-M(:)) < eps )

where the (:)-notation means that the matrix K and M should be expanded to column-vectors prior to the comparison. This is because all() works down a single dimension, so all(K==M) would still be a matrix (vector, actually, but that's a different name for a special case of the same thing). Notice that I don't use equality (==), but rather check whether their difference is smaller than some tiny value (eps). This is because in floating-point arithmetic (which all computers use), operations like multiplication and square root usually suffer from things like round-off error and approximation/interpolation error. An equality is a very tough demand, too tough to evaluate to true in most cases where it mathematically speaking should. You can prevent this failure to detect the equality by comparing the difference of the two to a tiny value that's related to round-off error (eps).

Fifth on the list is the way you print things. The print statement, by itself, will send a figure to the system's default printer, you know, that moody machine that spits out paper with ink on it if it feels like cooperating today :) Now, I assume you were trying to display things on the screen. Doing it like the way you set out to display things is not the best way: you'll get a dozen times this list of unnamed, unstructured values:

1     % which would be the value of 'a'
1     % which would be the value of 'b'
3     % which would be the value of 'd'
4     % which would be the value of 'e'
5     % which would be the value of 'f'
...

Seeing only the values appear makes reading and interpreting what's going on rather tedious. Better use something more descriptive:

if all( abs(K(:)-M(:)) < eps )

    % option 1
    a
    b
    d   % NOTE: not terminating with semicolon
    e
    f

    % option 2
    fprintf(...
        'a: %d
, b: %d
, d: %d
, e: %d
, f: %d

', a,b,d,e,f); 

end

Option 1 will just show

a = 
    1
b = 
    1
etc.

which at least also shows the variable's name alongside its value. Option 2 is the nicer one:

a: 1
b: 1
d: 3
e: 4
f: 5

a: 1
b: 2
d: 3
e: 4
f: 5

etc.

(As an aside, the values a,b,d,e,f never change in the loops, so why would you want to show them in the first place?)

Sixth (and last!) on the list, is one that is specific to Matlab: for-loops. Matlab is an interpreted, matrix-based language. Its matrix nature simply means that every variable is in essence, a matrix. Interpreted means that your code will not directly be seen by the computer's processor, it will have to go through a series of interpretations and translations before anything gets calculated. This coin has two sides:

• it can speed things up (like coding, or doing "trivial" things like solving linear systems, FFT, comparisons of matrices, etc.)
• it can slow things down (like repeated execution of statements, like in a loop)

In light of performance, the for-loop is notorious in Matlab for bringing operations to a crawl. The way to go in Matlab is usually vectorized code, e.g., use the fact that all variables are matrices, and use matrix/tensor operations on them instead of loops. This is not a very common approach in most programming languages (and you'll see a lot of strong, heated resistance to it in programmers not accustomed to it), but in a mathematical context it makes a whole lot of sense. Always try to use matrix/tensor operations as a first line of attack (and Matlab has a lot of them, mind you!) before resorting to for-loops.

So, that's what's wrong with your code :) Oh yeah, and as Andreas Hangauer already mentioned, place the statements referring to a through l, and all that needs to be re-calculated accordinly, inside the loop, and you'll be fine.