Clear Filters
Clear Filters

Did the default rounding behaviour of num2str change between R2016b and R2018b?

3 views (last 30 days)
I have some code that produces a different result when run in R2018b than it did in R2016b, and I've identified that num2str (which is used to create a text file to exchange data with an external tool) is giving different output for some values. For example, in R2016b:
>> num2str(1.51535)
ans =
1.5154
but in R2018b:
>> num2str(1.51535)
ans =
'1.5153'
I can work around this difference, but I can't find anything about this change in the MATLAB release notes, so before I commit any code changes I want to be sure that this is actually a change in MATLAB's default behaviour and not some setting I've overlooked that might be different between my R2016b and R2018b installations. Is this the case?
  2 Comments
Tom Hawkins
Tom Hawkins on 9 Nov 2018
Just for reference, in R2016b:
>> num2str(1.51535-eps)
ans =
1.5153
while in R2018b:
>> num2str(1.51535+eps)
ans =
'1.5154'
To me the expected behaviour is the R2016b version, i.e. round to nearest, ties to even - unless I've misunderstood how that's meant to apply when the underlying representation is binary rather than decimal.
Stephen23
Stephen23 on 9 Nov 2018
Edited: Stephen23 on 9 Nov 2018
I think the R2018 result is correct. Floating point binary is simply rounded to the nearest decimal value, because what you have is not a tie of the binary value relative to the rounded decimal value (for a tie the value could be something like 1+pow2(-53), or similar). In any case, I think that that value should be rounded down:
>> fprintf('%.30f\n',1.51535)
1.515349999999999974775732880516
Try using James Tursa's excellent FEX submission:
Of course this does not answer your question, "what changed?".

Sign in to comment.

Accepted Answer

James Tursa
James Tursa on 9 Nov 2018
Edited: James Tursa on 9 Nov 2018
The change appears to have occurred in R2017b. E.g., on Windows:
>> num2strexact(1.51535)
ans =
'1.5153499999999999747757328805164434015750885009765625'
R2016b:
>> num2str(1.51535)
ans =
1.5154
R2017a:
>> num2str(1.51535)
ans =
'1.5154'
R2017b:
>> num2str(1.51535)
ans =
'1.5153'
R2018a:
>> num2str(1.51535)
ans =
'1.5153'
R2018b:
>> num2str(1.51535)
ans =
'1.5153'
Looking closer, it appears they have switched the library functions they use behind the decimal conversion functions (maybe to make them more like their UNIX counterparts that have behaved this way for years?). E.g., again on Windows:
R2017a:
>> sprintf('%70.60f',1.51535)
ans =
' 1.515350000000000000000000000000000000000000000000000000000000'
R2017b:
>> sprintf('%70.60f',1.51535)
ans =
' 1.515349999999999974775732880516443401575088500976562500000000'
UNIX versions of MATLAB have been doing the full decimal digit conversion for years, and it appears that now the Windows versions of MATLAB do the same as of R2017b. So my guess is that MATLAB has changed some of the underlying library code they use for this (and possibly other) stuff in the background.
IMO this change is a good thing and an improvement, as it gives a more correct result to decimal conversions and also makes MATLAB results more consistent across different platforms.

More Answers (0)

Categories

Find more on Install Products in Help Center and File Exchange

Products


Release

R2018b

Community Treasure Hunt

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

Start Hunting!