Potential Differences Messages - MATLAB & Simulink (original) (raw)

When you enable potential differences reporting, the code generator reports potential differences between the behavior of the generated code and the behavior of the MATLAB® code. Reviewing and addressing potential differences before you generate standalone code helps you to avoid errors and incorrect answers in generated code.

Here are some of the potential differences messages:

Automatic Dimension Incompatibility

In the generated code, the dimension to operate along is selected automatically, and might be different from MATLAB. Consider specifying the working dimension explicitly as a constant value.

This restriction applies to functions that take the working dimension (the dimension along which to operate) as input. In MATLAB and in code generation, if you do not supply the working dimension, the function selects it. In MATLAB, the function selects the first dimension whose size does not equal 1. For code generation, the function selects the first dimension that has a variable size or that has a fixed size that does not equal 1. If the working dimension has a variable size and it becomes 1 at run time, then the working dimension is different from the working dimension in MATLAB. Therefore, when run-time error checks are enabled, an error can occur.

For example, suppose that X is a variable-size matrix with dimensions 1x:3x:5. In the generated code, sum(X) behaves like sum(X,2). In MATLAB, sum(X) behaves like sum(X,2) unless size(X,2) is 1. In MATLAB, when size(X,2) is 1, sum(X) behaves like sum(X,3).

To avoid this issue, specify the intended working dimension explicitly as a constant value. For example, sum(X,2).

mtimes No Dynamic Scalar Expansion

The generated code performs a general matrix multiplication. If a variable-size matrix operand becomes a scalar at run time, dimensions must still agree. There will not be an automatic switch to scalar multiplication.

Consider the multiplication A*B. If the code generator is aware that A is scalar and B is a matrix, the code generator produces code for scalar-matrix multiplication. However, if the code generator is aware that A and B are variable-size matrices, it produces code for a general matrix multiplication. At run time, if A turns out to be scalar, the generated code does not change its behavior. Therefore, when run-time error checks are enabled, a size mismatch error can occur.

Matrix-Matrix Indexing

For indexing a matrix with a matrix, matrix1(matrix2), the code generator assumed that the result would have the same size as matrix2. If matrix1 and matrix2 are vectors at run time, their orientations must match.

In matrix-matrix indexing, you use one matrix (the index matrix) to index into another matrix (the data matrix). In MATLAB, the general rule for matrix-matrix indexing is that the dimensions of the result are the same as the dimensions of the index matrix. For example, ifA and B are matrices,size(A(B)) equals size(B). However, whenA and B are vectors, MATLAB applies a different rule. When performing vector-vector indexing, the orientation of the result is the same as the orientation of the data matrix. For example, ifA is 1-by-5 and B is 3-by-1, thenA(B) is 1-by-3.

The code generator attempts to apply the same matrix-matrix indexing rules as MATLAB. If A and B are variable-size matrices at code generation time, the code generator follows the general MATLAB indexing rule and assumes that size(A(B)) equalssize(B). At run time, if A andB are vectors with different orientations, then this assumption is incorrect. Therefore, when run-time error checks are enabled, an error can occur.

To avoid this run-time error, try one of these solutions:

If A or B is a fixed-size matrix at run time, define this matrix as fixed-size at code generation time.
If A and B are both vectors at run time, make sure that their orientations match.
If your code intentionally accepts matrices as well as vectors of different orientations at run time, include an explicit check for vector-vector indexing and force vectors into the same orientation. For example, use the isvector function to determine whether both A and B are vectors and, if so, use the colon operator to force both vectors to be column vectors.
...
if isvector(A) && isvector(B)
Acol = A(:);
Bcol = B(:);
out = Acol(Bcol);
else
out = A(B);
end
...

Vector-Vector Indexing

For indexing a vector with a vector, vector1(vector2), the code generator assumed that the result would have the same orientation as vector1. If vector1 is a scalar at run time, the orientation of vector2 must match vector1.

In vector-vector indexing, you use one vector (the index vector) to index into another vector (the data vector). In MATLAB, the rule for vector-vector indexing is that the orientation of the result vector is the same as the orientation of the data vector. For example, if A is 1-by-5 and B is 3-by-1, then A(B) is 1-by-3. However, this rule does not apply if A is a scalar. If A is scalar, then the orientation of A(B) is the same as the orientation of the index vectorB.

The code generator attempts to apply the same vector-vector indexing rules as MATLAB. If A is a variable-size vector at code generation time, the code generator assumes that the orientation of A(B) is the same as the orientation of A. However, this assumption is false and a run time error occurs if both of these conditions are true:

At code generation time, the orientation of A does not match that of B.
At run time, A is a scalar and B is a vector.

To avoid this run-time error, try one of these solutions:

If A is a scalar at run time, define A as a scalar at code generation time.
If A and B are defined as vectors at code generation time, make sure that their orientations are the same.
If A and B are variable-size vectors with different orientations at code generation time, make sure that A is not a scalar at run time.
If A and B are variable-size vectors with different orientations at code generation time, make sure that B is not a vector at run time.

Loop Index Overflow

The generated code assumes the loop index does not overflow on the last iteration of the loop. If the loop index overflows, an infinite loop can occur.

Suppose that a for-loop end value is equal to or close to the maximum or minimum value for the loop index data type. In the generated code, the last increment or decrement of the loop index might cause the index variable to overflow. The index overflow might result in an infinite loop.

When memory integrity checks are enabled, if the code generator detects that the loop index might overflow, it reports an error. The software error checking is conservative. It might incorrectly report a loop index overflow. By default, memory-integrity checks are enabled for MEX code and disabled for standalone C/C++ code. See Check for Issues in MATLAB Code Using MEX Functions and Generate Standalone C/C++ Code That Detects and Reports Run-Time Errors.

To avoid a loop index overflow, use the workarounds in this table.