rounding error?!

Hi, in one of our apps the round function seems to be returning inconsistent results. E.g. an aggregate of values results in £38.675. We then add a few additional costs of £9.25 and we arrive at a grand total of £47.925. We round it to 2 decimal points using the following (all very standard I think): $grandTotal = £47.925 round ($grandTotal, 2) We get £47.92?!!!! My calculations on paper end up with 47.93. We have checked on thousands of records and we are getting a discrepancy of 1p in each. Sometimes up, sometimes down. The example above I would expect the result to be £47.93. I have isolated the first result, and round it there, and got £38.67, instead of £38.68!!! Is there a known bug for this round function in version 422? LR.
3 answers

You are right, scary things going on here, you should file a bug report:

round(3.385, 2) = 3.39, ok
round(3.375, 2) = 3,37  WRONG
round(3,365, 2) = 3,37, ok

With a simple loop 38 to 39 step 0.01 it seems that following go wrong:


so it is no freak number but a systematic error.

Rounding with 1 and 3 digits are all right in this range.


This is what I have done:

before it was outputting the following: round (val1, 2) + round (val2, 2) or round (val1 + val2, 2)

round (38.675, 2) + round (9.25, 2) resulting in 38.67 + 9.25 = 47.92, which is incorrect.

I then done the following calculation instead:

[round (val1 * 100) : 100] + [round (val2 * 100) : 100]

The result is: (3868 : 100) + (925 : 100) = 38.68 + 9.25 = 47.93 This is now correct. I don't know why, but the round with the 2 decimal points is set in mendix activity is not producing the correct result. LR.


This is actually not 'wrong', it's called round half to even or also called bankers rounding. Some methods of rounding have an upward or downward bias, 'round half to even' prevents this.

From Wikipedia ( :

Round half to even

A tie-breaking rule that is less biased is round half to even, namely:

If the fraction of y is 0.5, then q is the even integer nearest to y.

Thus, for example, +23.5 becomes +24, as does +24.5; while −23.5 becomes −24, as does −24.5.

This method treats positive and negative values symmetrically, and is therefore free of sign bias. More importantly, for reasonable distributions of y values, the expected (average) value of the rounded numbers is the same as that of the original numbers. However, this rule will introduce a towards-zero bias for even numbers (including zero), and a towards-infinity bias for odd ones.

This variant of the round-to-nearest method is also called unbiased rounding, convergent rounding, statistician's rounding, Dutch rounding, Gaussian rounding, odd-even rounding,[3] bankers' rounding or broken rounding, and is widely used in bookkeeping.

This is the default rounding mode used in IEEE 754 computing functions and operators.