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

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?

[Tom Hawkins]

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]

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:

https://www.mathworks.com/matlabcentral/fileexchange/22239-num2strexact-exact-version-of-num2str

Of course this does not answer your question, "what changed?".

Answer 1

[James Tursa]

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.