To convert MATLAB® code to efficient C/C++ code, the code generator introduces optimizations that intentionally cause the generated code to behave differently, and sometimes produce different results, than the original source code.
Here are some of the differences:
MATLAB supports 16-bit characters, but the generated code represents characters in 8 bits, the standard size for most embedded languages like C. See Encoding of Characters in Code Generation.
Generated code does not enforce order of evaluation in expressions. For most expressions, order of evaluation is not significant. However, for expressions with side effects, the generated code may produce the side effects in different order from the original MATLAB code. Expressions that produce side effects include those that:
Modify persistent or global variables
Display data to the screen
Write data to files
Modify the properties of handle class objects
In addition, the generated code does not enforce order of evaluation of logical operators that do not short circuit.
For more predictable results, it is good coding practice to split expressions that depend on the order of evaluation into multiple statements.
Rewrite
A = f1() + f2();
as
A = f1(); A = A + f2();
so that the generated code calls f1
before f2
.
Assign the outputs of a multi-output function call to variables that do not depend on one another. For example, rewrite
[y, y.f, y.g] = foo;
as
[y, a, b] = foo; y.f = a; y.g = b;
When you access the contents of multiple cells of a cell array, assign the results to variables that do not depend on one another. For example, rewrite
[y, y.f, y.g] = z{:};
as
[y, a, b] = z{:}; y.f = a; y.g = b;
Generated code does not match the termination behavior of MATLAB source code. For example, if infinite loops do not have side effects, optimizations remove them from generated code. As a result, the generated code can possibly terminate even though the corresponding MATLAB code does not.
For variable-size N-D arrays, the size
function
might return a different result in generated code than in MATLAB source
code. The size
function sometimes
returns trailing ones (singleton dimensions) in generated code, but
always drops trailing ones in MATLAB.
For example, for an N-D array X
with dimensions [4
2 1 1]
, size(X)
might return [4
2 1 1]
in generated code, but always
returns [4 2]
in MATLAB. See Incompatibility with MATLAB in Determining Size of Variable-Size N-D Arrays.
The size of an empty array in generated code might be different from its size in MATLAB source code. See Incompatibility with MATLAB in Determining Size of Empty Arrays.
Deleting all elements of an array results in an empty array. The size of this empty array in generated code might differ from its size in MATLAB source code.
Case | Example Code | Size of Empty Array in MATLAB | Size of Empty Array in Generated Code |
---|---|---|---|
Delete all elements of an m-by-n
array by using the colon operator (: ). | coder.varsize('X',[4,4],[1,1]);
X = zeros(2);
X(:) = [];
| 0-by-0 | 1-by-0 |
Delete all elements of a row
vector by using the colon operator (: ). | coder.varsize('X',[1,4],[0,1]);
X = zeros(1,4);
X(:) = []; | 0-by-0 | 1-by-0 |
Delete all elements of a column
vector by using the colon operator (: ). | coder.varsize('X',[4,1],[1,0]);
X = zeros(4,1);
X(:) = []; | 0-by-0 | 0-by-1 |
Delete all elements of a column vector by deleting one element at a time. | coder.varsize('X',[4,1],[1,0]); X = zeros(4,1); for i = 1:4 X(1)= []; end | 1-by-0 | 0-by-1 |
The generated code might not produce the same floating-point numerical results as MATLAB in these:
When computer hardware uses extended precision registers
The generated code might not produce exactly the same pattern of NaN
and
Inf
values as MATLAB code when these values are mathematically meaningless. For
example, if MATLAB output contains a NaN
, output from the
generated code should also contain a NaN
, but not necessarily
in the same place.
In a floating-point type, the value 0
has either a positive
sign or a negative sign. Arithmetically, 0
is equal to
-0
. Division by 0
produces
Inf
, but division by -0
produces
-Inf
.
If the code generator detects that a floating-point variable takes only integer
values of a suitable range, then the code generator can use an integer type for the
variable in the generated code. If the code generator uses an integer type for the
variable, then the variable stores -0
as +0
because an integer type does not store a sign for the value 0
. If
the generated code casts the variable back to a floating-point type, the sign of
0
is positive. Division by 0
produces
Inf
, not -Inf
.
The coder.target
function returns different
values in MATLAB than in the generated code. The intent is to
help you determine whether your function is executing in MATLAB or
has been compiled for a simulation or code generation target. See coder.target
.
Before code generation, at class loading time, MATLAB computes class default values. The code generator uses the values that MATLAB computes. It does not recompute default values. If the property definition uses a function call to compute the initial value, the code generator does not execute this function. If the function has side effects such as modifying a global variable or a persistent variable, then it is possible that the generated code can produce different results that MATLAB produces. For more information, see Defining Class Properties for Code Generation.
When an object with property access methods is an input to or an output from an extrinsic function, simulation results can differ from MATLAB results if:
A get method reads a property value and modifies the value before returning it.
A set method modifies an input value before assigning it to the property.
A get method or a set method has side effects such as modifying a global variable or writing to a file.
If property access methods modify property values or have side effects, results can differ due to inconsistencies in the use of property access methods when MATLAB and the simulation software pass objects to each other. If you return an object from an extrinsic function, MATLAB passes the object to the simulation software. The simulation software creates its own version of the object. To provide property values to the object creation process, MATLAB calls get methods. The object creation process assigns these property values from MATLAB directly to the new object without calling set methods.
When you pass an object to an extrinsic function for execution in MATLAB, the simulation software passes the object to MATLAB. MATLAB creates its own version of the object. To provide property values to MATLAB, instead of using get methods, the simulation software directly reads the property values. To assign property values in the MATLAB version of the object, the creation process uses set methods.
To avoid differences in results between MATLAB and simulation, for objects that are inputs to or outputs from extrinsic functions, do not use property access methods that modify property values or have other side effects.
For more information, see Defining Class Properties for Code Generation.
The behavior of handle class destructors in the generated code can be different from the behavior in MATLAB in these situations:
The order of destruction of several independent objects might be different in MATLAB than in the generated code.
The lifetime of objects in the generated code can be different from their lifetime in MATLAB.
The generated code does not destroy partially constructed objects. If
a handle object is not fully constructed at run time, the generated code
produces an error message but does not call the
delete
method for that object. For a System
object™, if there is a run-time error in
setupImpl
, the generated code does not call
releaseImpl
for that object.
MATLAB does call the delete
method to destroy
a partially constructed object.
For more information, see Code Generation for Handle Class Destructors.
See Incompatibilities with MATLAB in Variable-Size Support for Code Generation.