Why is operation between column and row vector so slow

For example, lets define two vectors:

>> a = rand(20000,1);
>> b = rand(1,20000);

Now element wise divide them:

>> tic;a./b;toc
Elapsed time is 0.267177 seconds.
>> tic;a./b';toc
Elapsed time is 0.053040 seconds.

Notice that if the size of two vectors are the same, it is almost 5 times faster. Is this a bug? I'm not expecting to see such huge speed difference. And if this is the case perhaps I should review all my previous code to optimize for such characteristic.

Update: I found this in the doc, potentially a bug in the implicit expansion procedure?

Compatibility Considerations

expand all

Implicit expansion change affects arguments for operators

Behavior changed in R2016b

Starting in R2016b with the addition of implicit expansion, some combinations of arguments for basic operations that previously returned errors now produce results. For example, you previously could not add a row and a column vector, but those operands are now valid for addition. In other words, an expression like [1 2] + [1; 2] previously returned a size mismatch error, but now it executes.

If your code uses element-wise operators and relies on the errors that MATLAB previously returned for mismatched sizes, particularly within a try/catch block, then your code might no longer catch those errors.

For more information on the required input sizes for basic array operations, see Compatible Array Sizes for Basic Operations.

Update again: I just realize that the result is a square matrix. This is not a bug. Thanks guys!

[Bruno Luong]

Why it's a BUG? It's documented there.

[Stephen23]

"Notice that if the size of two vectors are the same, it is almost 5 times faster. Is this a bug?"

Have you compared the outputs? That will give you a clue why they require different times (hint: not a bug).

[Ken Wang]

I thought that mismatch in size could be solved easily by:

if size(a) == size(b)'

return a./b'

Now it looks like matlab is taking a numpy broadcasting-like route, although I don't see the benefit here.

Answer 1

[DGM]

I'm assuming you're running R2016b or newer, otherwise that first test won't work. The vectors are the same length, but the two expressions don't produce the same results because of the vector orientation.

In this case, the vectors do not share the same geometry. Due to implicit expansion, x will be 200000x200000. You must have a pretty nice computer if it takes only 270ms and fits in memory.

x=a./b;

In this case, the vectors share the same geometry, and x will only be 200000x1, just like a.

x=a./b';

That much alone is enough to be a big difference, but as an aside, doing a single pass with tic/toc is usually going to be pretty inaccurate, especially if the thing being timed is fast. Consider timing multiple passes and averaging them. Alternatively, you can use timeit(), or open timeit.m and look at the things its doing to isolate the timing calculations from the influence of the environment.

[Ken Wang]

I think I've typed in an extra zero, the time was on the 20,000 size vectors : )