sprintf, round-off, floating point bug?

I'm using matlab 5.2 which is very old on UNIX system.

sprintf('%5.0f', 22.5) return '22'. Is this normal?

matlab R2010a returns '23' which seems like normal.

[Thorsten]

I get the same result for Matlab R2012a on Mac OS X 10.9.5:

>> sprintf('%5.0f', 22.5)

ans =
     22

[Stephen23]

MATLAB 2012b on Windows 7:

>> sprintf('%5.0f', 22.5)
ans =
   23

MATLAB 2009b on Windows 7:

>> sprintf('%5.0f', 22.5)
ans =
   23

But interestingly Octave 4.0.0 on Windows 7:

>> sprintf('%5.0f', 22.5)
ans =    22

[Stephen23]

I found a new, similar bug. Earlier versions correctly round the last digit up to 5:

>> sprintf('%.4g',1.2345e9) % R2009b

ans =

1.235e+009

>> sprintf('%.4g',1.2345e9) % R2010b

ans =

1.235e+009

>> sprintf('%.4g',1.2345e9) % R2013b

ans =

1.235e+09

>> sprintf('%.4g',1.2345e9) % R2018b

ans =

'1.235e+09'

But recent versions truncate/round the last digit down to 4:

>> sprintf('%.4g',1.2345e9) % R2021a

ans =

'1.234e+09'

sprintf('%.4g',1.2345e9) % R2021b (or whatever is used on this forum)

ans = '1.234e+09'

The value stored in memory seems to be the same in all cases:

format hex
1.2345e9

ans = 
   41d2653e68000000

[James Tursa]

MATLAB changed the underlying Windows library for the floating point binary to decimal conversion in R2017b. You can see this by printing out more than 17 decimal digits of a random double (older versions printed out trailing 0's, newer versions print out the exact conversion). This may have something to do with the differences. But Stephen's example seems to indicate yet another change to the background conversion code? Unfortunately I don't have the newest versions installed to investigate.

Answer 1

[James Tursa]

I don't have all the versions installed necessary to investigate all of the results posted above, but this may simply be a "ROUND TO EVEN" background algorithm being employed for decimal conversions rather than a "bug". In such case rounding 22.5 would correctly result in 22. Rounding 23.5 would round to 24 in this scheme. Similar thing might be happening with Stephen's example of 1.2345e9 where a "ROUND TO EVEN" algorithm would be expected to produce the 1.234e9 output, but a 1.2355e9 would be expected to produce a 1.236e9 output. It would be interesting to compare the outputs of sprintf( ), fprintf( ), round( ), etc. for the different MATLAB versions to see if things are consistent. Again, I can't investigate at the moment because I don't have the various MATLAB versions installed on the machine I am using.

[Stephen23]

Some similar values using the current version used on this forum:

sprintf(' %.4g',[1.2315e9,1.2325e9,1.2335e9,1.2345e9,1.2355e9,1.2365e9,1.2375e9,1.2385e9,1.2395e9])

ans = ' 1.232e+09 1.232e+09 1.234e+09 1.234e+09 1.236e+09 1.236e+09 1.238e+09 1.238e+09 1.24e+09'

That seems to match your hypothesis of round-half-to-even. In contrast R2018a uses round-half-up:

>> sprintf(' %.4g',[1.2315e9,1.2325e9,1.2335e9,1.2345e9,1.2355e9,1.2365e9,1.2375e9,1.2385e9,1.2395e9])

ans =

' 1.232e+09 1.233e+09 1.234e+09 1.235e+09 1.236e+09 1.237e+09 1.238e+09 1.239e+09 1.24e+09'

However I cannot find any reference to such a change, perhaps I searched for the wrong terms:

https://www.mathworks.com/help/matlab/release-notes.html?rntext=sprintf&startrelease=R2018a&endrelease=R2021b&groupby=release&sortby=descending&searchHighlight=sprintf

Answer 2

[Steven Lord]

Regarding the newer messages in this discussion, see this Answers post.