Why does .* create a matrix when multiplying a row vector by a column vector

I am a longtime matlab user and somehow only now running into this issue that seems like strange behavior to me. When multiplying one dimensional vectors element wise, I don't expect there to be a difference between column and row vectors since they are both 1-D. Yet, when you multiply a row vector using .* by a column vector you do not get a 1D vector you get a matrix.

a=1:3;
b=[2
    2
    2];
c=a.*b

c =

     2     4     6
     2     4     6
     2     4     6

     
     
     

Why does this happen? After some reading I learned matlab has 'implicit expansion' which is what I assume is happening. But I guess my deeper question is why is this a feature? If this is the result I wanted, I would do actual vector multiplication, b*a which gives the same result.

I am currently making a function that accepts vector inputs, and now I have to add some lines to check to make sure that all inputs are the correct orientation. To be specific, I am trying to calculate [1 2 3] .* [2 2 2]=[2 4 6] and have my answer be a vector. A matrix result would be meaningless in my case. I see the otions as either manually varify that the vectors passed to the function are same orientation, or have code that checks the orientation of each line (using size() for example) and transpose vectors as necessary. I am frustrated that these are the only options and wondering if there is a quicker solution.

Answer 1

[Askic V]

You don't need to write extra code to check orientation. I would use this:

c = a(:).*b(:)

It is only a bit more to code.

BTW, you have found the anwer to your question yourself regarding implicit expansion.

[Torsten]

You don't need to write extra code to check orientation. I would use this:

c = a(:).*b(:)

It is only a bit more to code.

And how does this help to check for the orientation of the vectors ? What if you want c = dot(a,b) ?

[Askic V]

Torsten, you're right, but from the question itself it was obvious to me that OP has 1D vectors with the same number of elements and wants to have a 1 D vector as a result of element wise multiplication. It was clear to me that he doesn't try to compute dot product. That is why I suggested this solution, which I think works for him.

But in general case, I agree the best practice is to check the orientation (row or column vector), but for his application, I think my suggestion can work just fine.

[Evan]

to clarify, I don't care what the orientation of the vectors are except that I don't want to invoke implicit expansion (which gives me a meangingless result in this case) so I am forced to ensure the vectors are the same orientation. Askic's answer is very helpful actually, allowing me to perform element wise multiplication on either row vectors or column vectors without haveing to check the size of each input separately.

Answer 2

[Torsten]

Why does this happen? After some reading I learned matlab has 'implicit expansion' which is what I assume is happening. But I guess my deeper question is why is this a feature? If this is the result I wanted, I would do actual vector multiplication, b*a which gives the same result.

There have been long discussions in the forum whether this feature of implicit expansion is useful or not and whether it may hide errors in programming. The majority of people voted that the advantages overweigh the disadvantages. I think we shouldn't open a new discussion about the usefulness of this feature.

I am currently making a function that accepts vector inputs, and now I have to add some lines to check to make sure that all inputs are the correct orientation.

So you don't trust in your programming or the inputs provided by anonymous users of your function ?

[Evan]

my function is just for my own use but in different places the input variables may have different orientations. I would like my function to be agnostic to the inputs being column/row to make it easier for me to use later.

I regret to have not been present to participate in the long discussions but consider this a strong vote in the 'implicit expansion is a stupid feature' category

[Torsten]

I would like my function to be agnostic to the inputs being column/row to make it easier for me to use later.

So independent of the orientation of a and b, you want to get a.*b as a and b being multiplied elementwise ? But here is where the problem begins: should the resulting a.*b be a row or a column vector ? If you only use the result in your own code, it might not be important for later use. But if you use it in a MATLAB solver, e.g., it will almost always matter - even if the implicit expansion feature had not been introduced.

[Evan]

In most cases it would not matter. I see how that would be ambiguous but that could easily be resolved by having the result take the orientation of the first variable as a rule. Only time it would matter is if I were using the vector in matrix multiplication but in those cases I would have to be very conscious of the vector orientation anyways