Rounding is generally a pretty straightforward topic: when you round, round to the nearest number for the level of precision specified. Confusion is introduced when the value to be rounded is exactly half way between the two possible values. This section is designed to explain and document how Helix rounds those values.
For the sake of illustration, we will deal with rounding to the nearest integer, typically done with Helixs Round tile.
Keep in mind that these same rules apply to the Round to Nearest tile, which allows you to specify the rounding precision.
Rounding always seeks the nearest value to round to, but when the original value is exactly half way between the target values, Helix employs one of two distinct sets of rounding rules. The rounding rules used depend on the data type being rounded.
The rules below only apply to values that fall exactly half way between the two possible values. All other values round to the nearest number.
Fixed Point data (technically, integers) were introduced much later in Helixs history and have always used the financial rounding method. Financial rounding seeks to make rounding more predictable, so it rounds away from zero, thereby guaranteeing consistent rounding.
Financial rounding is also known as "symmetric arithmetic rounding," "banker's rounding," and a few others names. There are also variations on the basic rules for financial rounding always rounding toward zero is one common variation so be aware that not everybody has the same rules in mind when speaking about financial rounding.
To see financial rounding in another setting, open Apples ScriptEditor and run this AppleScript (make sure the event log is open so you can see the results).
repeat with i from -10 to 10 get round (i + 0.5) rounding as taught in school end repeat
In AppleScript, as taught in school uses financial rounding, and you will get the exact answers tht Helix produces when rounding data in fixed point format.
Number data (technically, floating point numbers) were introduced in the very first version of Helix and have always used the scientific rounding method. Scientific rounding seeks to minimize cumulative errors, so it rounds to the nearest even number, thereby reducing the possibility that the result will be skewed.
To see scientific rounding in another setting, open Apples ScriptEditor and run this simple AppleScript (make sure the event log is open so you can see the results).
repeat with i from -10 to 10 get round (i + 0.5) rounding to nearest end repeat
In AppleScript, to nearest uses scientific rounding, and you will get the same answers as Helix produces when rounding data in number format.
Certain numbers can be seen to violate the specification for scientific rounding. This problem is introduced because computers typically convert decimal (as in base 10) numbers into their binary (base 2) equivalents before doing mathematic operations. In decimal math, we have many fractional values (e.g. 1/3) that we understand to be infinitely repeating decimal numbers. Attempting to divide 100 identical items evenly between three people is impossible. Doing mathematical operations along this line introduces rounding errors that we naturally understand and for which we compensate. A human being can look at ((100/3)*3) and understand that the answer is 100, but if you work it out, the answer comes out as 99.999& and we simply round it off to 100. But it is important to keep in mind that 100 is an approximation, the real answer is 99.999...
When examining binary numbers, you find that a whole different series of fractional numbers turn out to be infinitely repeating. For example 1/10 is an infinitely repeating binary number.
Now consider how this applies to rounding. Given the number .235 and being asked to round to the nearest .01, you would apply the financial rounding rules and arrive at the (correct) answer of .24. However, Helix rounds this to .23.
Why? The answer is binary conversion error. 235/1000 is, when expressed as a binary number, an infinitely repeating number. Converting 235/1000 to binary and then back to decimal will yield (approximately) .23499999& Because this value is not exactly half way between the two numbers we are potentially rounding to, it is rounded to the nearest value (down, in this case) and the result appears incorrect.
Why does Helix make this mistake? The math routines that Helix uses are part of the Macintosh CPUs ROM: they are part of the common package that most programs use.
Open your Calculator DA and type 1-.9-.1= and you'll see that the answer is not "0". Remember that 1/10 (.1 in decimal notation) can not be accurately represented in binary: it is an infinitely repeating value. The value has to be approximated, and the minute error is seen when math operations are performed.
If you do not need more than two decimal places of precision, you can avoid these rounding errors by converting the number into a Fixed Point data type before performing math operations, converting the result back to a number data type, if necessary.