MATLAB Answers

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

4 views (last 30 days)
Tom Hawkins
Tom Hawkins on 9 Nov 2018
Edited: James Tursa on 9 Nov 2018
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.
Stephen Cobeldick
Stephen Cobeldick 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.

  0 Comments

Sign in to comment.

More Answers (0)

Sign in to answer this question.

Products


Release

R2018b