Subtracting a vector from a variable-sized matrix in Simulink issue

Hi everyone, I’d like to share a problem I’m facing in Simulink. I have a matrix with a variable number of rows (e.g., [m * 3]), where m is typically around 1000. I need to subtract a [1 * 3] vector from this matrix.

I cannot use the 'Subtract' block directly because of the dimension mismatch. I tried resizing the vector, but since the matrix row count is dynamic, I couldn't find a flexible solution. The vector's dimensions are fixed, but its values change over time, so the 'Bias' block isn't an option. Furthermore, I specifically want to solve this using standard Simulink blocks only, without using a 'MATLAB Function' block.

Has anyone dealt with this type of dynamic broadcasting in Simulink? Any advice on which blocks to use would be greatly appreciated.

[dpb]

Does seem like the perfect place to use a S-function, though, despite the wish. "If frogs had wings..." <g>

Answer 1

[Umar]

Hi @Kadir,

I looked into your problem and there's actually a perfect block for this, but it depends on whether you have the DSP System Toolbox installed.

If you have DSP System Toolbox, use the Array-Vector Subtract block. You'll find it under DSP System Toolbox > Math Functions > Matrices and Linear Algebra > Matrix Operations. This block is designed exactly for what you need - it subtracts a vector from a matrix along a specified dimension and officially supports variable-size signals, so your dynamic m value won't be a problem.

Setup is straightforward:

Connect your [m×3] matrix to port A

Connect your [1×3] vector to port V (set Vector source to "Input port")

Set "Subtract along dimension" to 1

The block will automatically broadcast your [1×3] vector across all m rows and subtract it from each row. Since the documentation confirms it supports variable-size signals, m can change during simulation without any issues.

Full documentation here: https://www.mathworks.com/help/dsp/ref/arrayvectorsubtract.html

If you don't have the DSP toolbox, you have a few workarounds using standard blocks, but they're all more complicated:

The simplest approach is to process each column separately. Use three Selector blocks to extract each column from your [m×3] matrix, then use three Subtract blocks to subtract each element of your [1×3] vector from the corresponding column, and finally use Matrix Concatenate to put the columns back together. It's not elegant, but it works and doesn't require loops.

Alternatively, there's a Reshape and Selector method that can replicate your vector to match the matrix size, but it's pretty involved and requires dynamically getting m using a Width block.

For Each Subsystem that Fangjun mentioned would work too, but looping 1000 times per timestep is going to be slow.

Honestly,if you don't have DSP System Toolbox and these workarounds seem too messy, this is exactly the kind of situation where a MATLAB Function block makes sense. I know you wanted to avoid it, but sometimes it's the right tool for the job. Just a few lines of code and you're done.

Hope this helps!

[Kadir]

Yes, separate column processing works very well. Thanks for your advice. But I wonder why doing it with Simulink is more difficult than doing it in a Matlab Function. What is the main reason for this difference?

[Umar]

Hi @Kadir,

That is actually a really insightful question, and the answer gets to the heart of what Simulink is and what it is not.

Matlab is an interpreted scripting environment. When you write A - v where A is [m×3] and v is [1×3], MATLAB's runtime figures out the dimensions at that exact moment, broadcasts v across all m rows automatically, and returns the result. It does this dynamically, at execution time, with full knowledge of the actual sizes involved. There is no pre-planning required. The interpreter handles everything in one pass.

Simulink works completely differently. Before a simulation even starts, Simulink goes through a compilation and signal propagation phase where it statically determines the data type, dimensions, and sample time of every single wire in your model. Every block has to declare in advance what size of signal it will accept and what size it will output. This happens before any data flows. The Simulink engine then builds an execution schedule based on those fixed declarations, allocates memory accordingly, and only then begins the actual simulation. This is what allows Simulink to run efficiently for real-time and embedded targets, where dynamic memory allocation would be unacceptable.

The problem with broadcasting in that environment is that a standard Subtract block needs to know, at compile time, that its two inputs are exactly the same size. It cannot say "I will figure out the sizes later." When your matrix has a variable number of rows m, and the block needs to match that against your fixed [1×3] vector, the static type system does not have a built-in mechanism to express "replicate this vector to match whatever m turns out to be." That kind of implicit dimensional inference is simply not part of how most standard Simulink blocks are specified.

The column-by-column workaround sidesteps this entirely. Each Selector block extracts a fixed-width column (always m rows, 1 column), and each Subtract block subtracts a fixed scalar from it. The variable dimension m passes through unchanged because element-wise operations on a single column do not require knowing m ahead of time, they just operate on whatever length the signal has. The blocks that support variable-size signals, as documented in the Simulink Block Data Type Support table, are specifically designed and registered with the engine to handle that case. Most arithmetic blocks are not on that list.

The DSP System Toolbox's Array-Vector Subtract block is an exception precisely because it was purpose-built for this pattern. Its documentation explicitly states it supports variable-size signals, meaning its internal contract with the Simulink engine is written to handle a changing first dimension. That extra engineering work is what makes it capable of doing what a MATLAB one-liner does trivially.

The MATLAB Function block bridges the gap by essentially embedding MATLAB's interpreter inside Simulink. It lets you write y = u1 - u2 and the generated code handles the variable dimension in a way that is compatible with Simulink's execution framework. It is more powerful for this kind of operation precisely because it opts back into the flexible MATLAB world rather than working within the constraints of the block-by-block static type system.

So in short

MATLAB operates dynamically at runtime with full knowledge of actual data, while Simulink operates statically at compile time with only declarations. Broadcasting requires runtime knowledge of dimensions, and most standard blocks are not designed to carry or act on that information. The column approach works because it decomposes the problem into pieces where each piece has dimensions that are either fixed or already natively supported as variable-size.

Hope that clears it up. Great question.

Answer 2

[Fangjun Jiang]

Would "m" vary during a simulation? If not and it only varies between simulations, then you can use the "For Each

Subsystem" block to construct a for-loop in Simulink. Not ideal, but dorable without using the "MATLAB Function" block, which BTW, is perfect to use for your use case.

Or, since it has only 3 columns, the below approach is practical.

Use the "Selector" block to pick out the column, use the "Matrix Concatenate" block to combine the columns.

[Kadir]

A Loop is not ideal in my case because I am performing comprehensive analyses, and loops can increase the computational cost significantly. But the second approach you mentioned works very well. Since I only have 3 colums, I can move on using that method. Thanks a lot!

[Fangjun Jiang]

For-loop is not necessarily slow. I just realized that we could loop through the 3 columns. It becomes simple and elegant.