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
- 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.
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.
Shortest is not always unique
The shortest possible text that is round trip lossless is not always unique.
u = single(423350.16)
r = valueToRoundTripString(u,'single')
The shortest round trip lossless representation of this value uses 8 decimal digits.
But the text is not unique, three different text representations would all parse back to the same original value.
423350.15F
423350.16F
423350.17F
As an extreme example, consider the following example.
u = eps(single(0))
r = valueToRoundTripString(u,'single')
This value has four distinct one digit representations
8e-46F
9e-46F
1e-45F
2e-45F
All four textual representations will parse back to eps(single(0)).
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.
