# Well rounded

When PCalc 3.6.1 came out a little over a week ago, I saw something disturbing in the release notes:

Round function now always rounds half upwards to the nearest integer.

Blasphemy! I cried. For is it not written in that most holy of floating point standards, that one should round halves to even?1

Perhaps the release notes were wrong. I opened PCalc and began testing.

• 1.5 rounded to 2, which is consistent with PCalc’s previous behavior and correct.
• 2.5 rounded to 3, which is new and wrong.

I got on the Twitter and shot off a direct message to PCalc’s developer, James Thomson, asking, in effect, WTF? His reply was pretty much what I expected. He’d been getting complaints from people who expected (for positive numbers, anyway) that halves would always be rounded up.

This is an all-too-common belief, instilled in children by parents and elementary school teachers who were taught it by previous generations of misguided souls. You may believe it yourself; I certainly did until I became enlightened sometime in grad school.

The problem with always rounding halves up is that in doing so, you introduce a persistent bias in whatever calculations you do with the rounded number. If you’re adding a list of rounded numbers, for example, the sum will be biased high.2

If you round halves to the nearest even number, though, the bias from upward roundings tends to be negated by an equal number of downward roundings.3 Overall, you get better results.

James expected the rounding change to raise hackles, and he was thinking about how to provide rounding options before I DM’d him. PCalc 3.6.2, released today, is the result. There’s a new Rounding item in the Advanced Settings. Tapping it gives you these six choices:

The top option is what the great unwashed expect. The second is the One True Rounding. The others are specialized options that are often needed when doing integer calculations. The floor and ceiling roundings, for example, get used in things like the Doomsday Algorithm.

PCalc’s “round” function rounds to integers, but rounding also applies when you have the display set to show a limited number of decimal places.

With Nearest or Even rounding and two decimal places chosen, the numbers ⅛, –⅛, ⅞, and –⅞ will display like this:

Note that although this display rounding follows the same rule as the round function, the numbers in the display still retain, behind the scenes, all their digits. Therefore, if we enter ⅛, we’ll see 0.12 in the display, but the number is really 0.125. Multiplying by 2 will give us 0.25, not 0.24. This differs from the round function, which really does change whatever number it’s applied to into an integer.

I was perfectly happy with PCalc’s old behavior, which always rounded halves to even, but, shockingly, James has to consider the needs and wants of customers other than me. Now there’s rounding for everyone.

1. Yes, IEEE 754 does define other rounding rules, but round to nearest, ties to even is the default. ↩︎

2. I’m assuming positive numbers in this example. When numbers come from measurements, that’s the most common case. ↩︎

3. If you’re thinking Benford’s Law screws up the notion that there will be an equal number of upward and downward roundings, think again. Benford’s Law applies to the most significant digit; rounding is done to the least significant digit. Only if you’re rounding to one digit will Benford’s Law lead to significant bias. And even then, rounding halves to even is still less biased than rounding them up. ↩︎