Inconsistent Rounding of Printed Floating-Point Numbers

What does this C program print?

#include <stdio.h>
int main (void)
{
 printf ("%.1f\n",0.25);
}

The answer depends on which compiler you use. If you compile the program with Visual C++ and run on it on Windows, it prints 0.3; if you compile it with gcc and run it on Linux, it prints 0.2.

The compilers — actually, their run time libraries — are using different rules to break decimal rounding ties. The two-digit number 0.25, which has an exact binary floating-point representation, is equally near two one-digit decimal numbers: 0.2 and 0.3; either is an acceptable answer. Visual C++ uses the round-half-away-from-zero rule, and gcc (actually, glibc) uses the round-half-to-even rule, also known as bankers’ rounding.

This inconsistency of printed output is not limited to C — it spans many programming environments. In all, I tested fixed-format printing in nineteen environments: in thirteen of them, round-half-away-from-zero was used; in the remaining six, round-half-to-even was used. I also discovered an anomaly in some environments: numbers like 0.15 — which look like halfway cases but are actually not when viewed in binary — may be rounded incorrectly. I’ll report my results in this article.

The Tests

I tested the rounding of printed floating-point numbers in C, Java, Python, Perl, Visual Basic, PHP, JavaScript, VBScript, and OpenOffice.org Calc. I formatted two-digit decimal numbers as one-digit decimal numbers, as indicated in this table (the variable ‘d’ represents a double-precision variable):

To serve as a metric of sorts, I also tried David Gay’s g_fmt() function, the formatting wrapper for his floating-point to decimal conversion routine dtoa(). (I modified the code to make the call to dtoa() in “mode 3” with ndigits=1.)

For some of the eight programming languages, I tried multiple compilers or interpreters and ran on different operating systems, resulting in nineteen test environments. For each of the nineteen environments, I tried eight examples: 0.25, 0.75, -0.25, -0.75, 0.15, 0.85, 0.55, and 0.45. The first four numbers are exactly representable in binary, so are true halfway cases; they should round according to the tie-breaking rule in effect. The second four numbers are not exactly representable in binary, so are not halfway cases; the tie-breaking rule does not apply. Here are the double-precision floating-point approximations of the latter four values:

• 0.15 = 0.1499999999999999944488848768742172978818416595458984375
• 0.85 = 0.84999999999999997779553950749686919152736663818359375
• 0.55 = 0.5500000000000000444089209850062616169452667236328125
• 0.45 = 0.450000000000000011102230246251565404236316680908203125

The approximations of 0.15 and 0.85 are less than halfway between two one-digit decimal numbers, so should round down; the approximations of 0.55 and 0.45 are more than halfway between two one-digit decimal numbers, so should round up.

The Results

The environments fell into two basic groups, as expected: those that round-half-away-from-zero, and those that round-half-to-even. On top of that, some less than halfway cases were incorrectly rounded in some environments. Here are the results (the round-half-to-even results are shown in bold, and the incorrectly rounded results are shown in red):

What Caused The Incorrectly Rounded Results?

The incorrectly rounded printed results are likely due to double rounding. My guess is that the ‘not quite halfway’ cases are first rounded to 15 decimal digits — making them look like halfway cases — and then rounded to one digit. (The errors occurred only in environments where round-half-away-from-zero was used, which explains the consistent rounding up.)

To come to this conclusion, I had to rule out incorrect decimal to floating-point conversion of the test values. For the Java case — which is the only one I knew how to check — I printed the exact double-precision values of 0.15 of 0.85 using hexadecimal floating-point constants:

System.out.printf("%a\n",0.15);
System.out.printf("%a\n",0.85);

0.15 printed as 0x1.3333333333333p-3, and 0.85 printed as 0x1.b333333333333p-1; converted manually to decimal, these are the values I showed above, which are just below halfway between two one-digit values.

Should There Be a Universal Default Rounding Mode?

Why isn’t the same rounding mode used in all environments? It’s because there is no standard, unlike for decimal to floating-point conversions, which by default are universally done (or at least attempted) in round-to-nearest/round-half-to-even mode.

If there were to be a standard, what should the default rounding mode be? Should the user be able to change it? David Gay’s dtoa() is sensitive to a user chosen rounding mode, but the choices are the four IEEE 754 rounding modes. It’s not clear though why the IEEE floating-point rounding modes should apply to floating-point to decimal conversions; for one, round-to-nearest/round-half-away-from-zero is not even a choice.

Update 10/6/13: glibc printf() honors IEEE rounding mode

glibc printf() has been updated to take the current IEEE rounding mode into account. This was done in version 2.17; I just tested it on version 2.18. In doing it this way of course, round-to-nearest/round-half-away-from-zero is still not an option, so this doesn’t help you make its output consistent with other platforms.