Editing Kahan summation algorithm (section)

===Worked example===
The algorithm does not mandate any specific choice of [[radix]], only for the arithmetic to "normalize floating-point sums before rounding or truncating".<ref name="kahan65" /> Computers typically use binary arithmetic, but to make the example easier to read, it will be given in decimal. Suppose we are using six-digit decimal [[floating-point arithmetic]], <code>sum</code> has attained the value 10000.0, and the next two values of <code>input[i]</code> are 3.14159 and 2.71828. The exact result is 10005.85987, which rounds to 10005.9. With a plain summation, each incoming value would be aligned with <code>sum</code>, and many low-order digits would be lost (by truncation or rounding). The first result, after rounding, would be 10003.1. The second result would be 10005.81828 before rounding and 10005.8 after rounding. This is not correct.

However, with compensated summation, we get the correctly rounded result of 10005.9.

Assume that <code>c</code> has the initial value zero. Trailing zeros shown where they are significant for the six-digit floating-point number.
   y = 3.14159 - 0.00000             ''y = input[i] - c''
   t = 10000.0 + 3.14159             ''t = sum + y''
     = 10003.14159                   Normalization done, next round off to six digits.
     = 10003.1                       Few digits from ''input[i]'' met those of ''sum''. Many digits have been lost!
   c = (10003.1 - 10000.0) - 3.14159 ''c = (t - sum) - y''  (Note: Parenthesis '''must''' be evaluated first!)
     = 3.10000 - 3.14159             The assimilated part of ''y'' minus the original full ''y''.
     = -0.0415900                    Because ''c'' is close to zero, normalization retains many digits after the floating point. 
 sum = 10003.1                       ''sum = t''

The sum is so large that only the high-order digits of the input numbers are being accumulated. But on the next step, <code>c</code>, an approximation of the running error, counteracts the problem.
   y = 2.71828 - (-0.0415900)        Most digits meet, since ''c'' is of a size similar to ''y''.
     = 2.75987                       The shortfall (low-order digits lost) of previous iteration successfully reinstated.
   t = 10003.1 + 2.75987             But still only few meet the digits of ''sum''.
     = 10005.85987                   Normalization done, next round to six digits.
     = 10005.9                       Again, many digits have been lost, but ''c'' helped nudge the round-off.
   c = (10005.9 - 10003.1) - 2.75987 Estimate the accumulated error, based on the adjusted ''y''.
     = 2.80000 - 2.75987             As expected, the low-order parts can be retained in ''c'' with no or minor round-off effects.
     = 0.0401300                     In this iteration, ''t'' was a bit too high, the excess will be subtracted off in next iteration.
 sum = 10005.9                       Exact result is 10005.85987, ''sum'' is correct, rounded to 6 digits.

The algorithm performs summation with two accumulators: <code>sum</code> holds the sum, and <code>c</code> accumulates the parts not assimilated into <code>sum</code>, to nudge the low-order part of <code>sum</code> the next time around. Thus the summation proceeds with "guard digits" in <code>c</code>, which is better than not having any, but is not as good as performing the calculations with double the precision of the input. However, simply increasing the precision of the calculations is not practical in general; if <code>input</code> is already in double precision, few systems supply [[quadruple precision]], and if they did, <code>input</code> could then be in quadruple precision.