Kahan summation: Difference between revisions
m
→Third phase: what is being computed?: introducing an ad-hoc notion involving |
(→Third phase: what is being computed?: Details, details...) |
m (→Third phase: what is being computed?: introducing an ad-hoc notion involving |) |
||
Line 610:
= 101.1101110000 | 100000011101 This should be the result in the lower bits, the carry made.
101.1101110001 ^ This is the calculated result in the lower bits.
Because ''both'' values round up one (because the eleventh bit is a 1) in the actual calculation, the result is one bit high. But this is entirely proper, because the eleventh bit of the sum, by sheer chance, is a 1 (as seen above: below it is a ^), and so the plain summation is as accurate as it can be and the compensated addition can't do any better despite all its juggling. The double-precision result (from the 80-bit calculation) confirms this as the difference X4E - X8E of 4.813671112060547D-004 is 0.0000000000011111100011 in binary or | 011111100011, exactly the last value of C. It is calculated back-to-front compared to the hand calculation (above the ^) where the discrepancy is
=={{header|Go}}==
| |||