java.math package came with several rounding mode but there are 2 quite interesting ones: HALF_UP and HALF_EVEN rounding.
This is basically your elementary school rounding. If the fractions to be rounded are equidistant from its neighbor, then round them into the upper neighbour. In other words, if we’re rounding 1 digit after decimal, then if it ends with .5 just add .5. For example:
Similar like HALF_UP, except if the fraction is equidistant, round them into nearest even neighbor. For example:
Why Bother With HALF_EVEN?
Why don’t we just stick with what’s learned in elementary school? Well here’s one good reason: accumulative error. Error here means “How much did we lose/gain by rounding the number?”. Let’s take a look again to both table with its rounding error displayed
|Fractional Number||HALF_UP rounding||HALF_UP rounding error||HALF_EVEN rounding||HALF_EVEN rounding error|
As you can see the accumulative errors for HALF_UP is incrementally higher whereas HALF_EVEN averages out. This is why HALF_EVEN is often called “Banker’s rounding” because given a large amount of data the bank should not gain/loss money because of rounding.
More Surprises With printf
Don’t yet assume all programming language defaults into HALF_EVEN, try below examples of printf in your shell:
$ printf "%.5f" 1.000015 1.00002 $ printf "%.5f" 1.000025 1.00002 $ printf "%.5f" 1.000035 1.00004 $ printf "%.5f" 1.000045 1.00005
Wait.. what? Isn’t 1.000045 supposed to be rounded to 1.00004? Well in floating point realm the reality is more complicated than that, taking into account floating point is often never accurate in the first place.
Try printing 1.000045 with long enough digits after decimal:
$ printf "%.30f" 1.000045 1.000045000000000072759576141834
Now you can see computers can’t always store accurate value of real numbers in floating point types. (And you should now see why it’s rounded into 1.00005)
Here’s some reading if you’re interested in this problem.