- EXACT value FOO represented in memory in MATLAB or Simulink
- "Exact enough" textual representation of the value FOO is created
- C, C++, HDL, etc. parser converts that text to a value in machine code / memory that is EXACTLY the same as the original value FOO.

# FAQ: Why does a value look more precise when displayed in MATLAB or Simulink than in the generated code?

2 views (last 30 days)

Show older comments

MathWorks Fixed Point Team
on 14 Dec 2022

Edited: Andy Bartlett
on 6 Feb 2023

A value used in my design looks more precise when displayed in MATLAB or Simulink.

The same value in C or C++ generated by Embedded Coder looks less precise.

For example

format long

u = single(7.5066509)

The same value appears in the generated code as

float u = 7.506651F;

Why is that?

##### 0 Comments

### Accepted Answer

Andy Bartlett
on 15 Dec 2022

Edited: Andy Bartlett
on 6 Feb 2023

Textual Representation is Often an Approximation

The textual representation of values displayed in MATLAB and Simulink is often an approximation of the value that is actually represented. To show the EXACT value represented in a numeric type can often be quite messy. It can even be exceedingly messy.

Example exact represented value is really messy

format long

v = eps(0)

eps(0) looks a bit messy when displayed in format long. But even that is an approximation.

The EXACT value represented in double requires over 750 digits to represent in decimal scientific notation.

vSym = sym(v,'f');

pow10Exp = floor(log10(abs(vSym)));

mantissaSym = vSym / (sym(10)^pow10Exp);

mantissaStr = char( vpa(mantissaSym, 10000) )

lenMantissaStr = length(mantissaStr)

fprintf('v = 10^%d * %s\n',pow10Exp, mantissaStr)

Faithful Numeric Agreement is Hugely Important

MathWorks Coders make it a priority for the numerics in MATLAB and Simulink to be faithfully matched by the C/C++/HDL code generated by Coders. MathWorks users get huge productivity boosts by detecting behavioral issues early in their workflows in the convienient and "safe" environment provided by MATLAB and Simulink. For integer and fixed-point, the expected agreement is bit-true. For floating-point, Coders try very hard to get as close as is reasonable to bit-true. A place where bit-true is definitely achieved for floating-point, fixed-point, and integer is the generation of code for constants.

Round-Trip Lossless is "Exact Enough" for Bit-True Constants in Generated Code

Since textual representations of values are very often approximations of the exact value represented in a numeric type, you may be wondering how Coders can achieve bit-true agreement with MATLAB and Simulink for constants.

The key is computer languages like C, C++, and MATLAB parse the text and map it to the closest representable value in the numeric type being used.

So Coders don't need to generate the whole messy text for the EXACT value. Coders just need to generate text that is close enough to the exact value such that the language's parser will map that text back to the identical value that was represented in MATLAB and Simulink.

In other words, there has to be a lossless round trip

Infinite choices for "Exact Enough" Text

As you know, there are an infinite number of values that will round to a value such as 3. When rounded to nearest representable integer, all the infinite values in the open interval (2.5, 3.5) will definitely round to 3.

Similarly, for a given representable value in a given numeric type, there are an infinite number of textual representations of the value that will parse back to the original given representable value. Proper parsing will provide a round to nearest representable behavior.

Let's consider the value provided in the original question, single(7.5066509).

The exact representation of that value and the two nearest representable values are the following.

valueNextRepAbove: '7.506651401519775390625'

valueExactRepr: '7.5066509246826171875'

valueNextRepBelow: '7.506650447845458984375'

Text will be "exact enough" for round-trip lossless handling if the symbolic interpretation of the textual value is closer to the middle of these three values than it is to the other two values. So if the textual value is between the two mid-points of this sequence of three values, then a correctly implemented parser will map that text to the desired exact value 7.5066509246826171875.

Example of "Exact Enough" Round-Trip Lossless Text

Utilizing the two attached functions, let's probe the value from the question.

u = single(7.506651)

r = valueToRoundTripString(u)

The 2nd to last field of the output structure shows one example of round trip lossless text for the original value. Notice that the text is clearly between the nearest representable mid-points.

valueMidpointToRepAbove: '7.5066511631011962890625'

textForC: '7.506651F'

valueMidpointToRepBelow: '7.5066506862640380859375'

Two examples of the many other C textual values that would also be round trip lossless are the following.

7.50665105F

7.5066507F

Any of the infinite values in the open interval

(7.5066506862640380859375, 7.5066511631011962890625)

will definitely map to the desired value 7.5066509246826171875 if the language's parser is correctly implemented.

Short is nice, but Shortest is NOT a priority

The shortest possible text that is round trip lossless is definitely appealing. When Coders generate text for a constant, that text will very often, but not always, be the shortest possible text. Sometimes the text can be a character or two longer than needed. It's nice to be shorter, but a few extra characters now and then have no impact on the faithful numeric agreement between the generated code and MATLAB and Simulink.

Doing the "optimization search" to find the exact shortest text can be time consuming. Many MathWorks user have made it clear that they value having Coders complete the code generation process quickly. This user feedback made it clear that productivity of users was more important that getting the absolute fewest characters 100% of the time.

Round trip lossless representation of constants is an absolute priority. Coders run lots of testing everyday to make sure that remains true. As mentioned above, numeric fidelity is a big productivity boost to users of MATLAB, Simulink, and Coders.

MATLAB Parser Plays by the Same Rules

Just like C, MATLAB has a parser that reads text that users like you and I write.

An infinite number of textual representations will parse to the same value.

vec = sort([

single(7.506651)

single(7.5066510000789)

single(7.5066507)

single(7.5066506900111111)

])

distinceValues = unique(vec)

All that different text really only produced one distinct value in single precision floating point. Longer text did NOT mean a precision difference.

Again, any textual representation in this interval

(7.5066506862640380859375, 7.5066511631011962890625)

when mapped in to single precision floating point will produce the EXACT value represented in single of 7.5066509246826171875.

Same Principles Apply to All Numeric Types

The question and examples have focused on singles, but don't draw a false conclusion that this is distinct to singles. The same principles apply to doubles, half, integer, fixed-point and so on.

For example, for the type double, any textual value in the open interval

(7.506650999999999296363739631487987935543060302734375, 7.506651000000000184542159331613220274448394775390625)

will be parsed by C, MATLAB, etc, to the EXACT representable value

7.5066509999999997404529494815506041049957275390625

one example of "exact enough" text is

7.506651

Takeaway "exact enough" text is what matters

In MATLAB, Simulink, C, etc., any text that is "exact enough" for the given type is equivalent. It may look different, but if it is "exact enough" it leads to the same representable value of the specific type being used.

##### 0 Comments

### More Answers (0)

### See Also

### Categories

### Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!