Kahan summation: Difference between revisions
m
→Third phase: what is being computed?: Re-align, to hint at correspondences, and the implicit bit.
m (→Third phase: what is being computed?: Re-align, to hint at correspondences, and the implicit bit.) |
|||
Line 393:
For the test data, all methods, including compensated summation, returned exactly the same result, even to the last bit, so one wonders just what is going on. Using decimal numbers when concerned with the exact details of binary arithmetic is troublesome because the conversions are generally inexact, so the plan is to reveal the numbers in base two. Besides F format, later Fortran version offers further options such as B O, and Z formats for binary, octal and hexadecimal (the code H being spoken for another use) however these present the bit-patterns as packed into the storage used for the variable, they do not reveal its ''numerical'' value in binary, etc. So, for 3.14159 in decimal,
100000001
11.001001000011111101 is that value in binary (three, plus an eighth, plus a sixty-forth, plus ...)
11.0010010000111111011011 is 4*ATAN(1) in single precision.
11.001001000011111101101010100010001000010110100011 is 4*ATAN(1) in double precision.
11.001001000011111101101010100010001000010110100011000010001101001100010... is more accurate.
It is a small relief to see that 4*ATAN(1) gives a correctly-rounded value - at least with this system. Specifying a decimal value, even if with additional digits, may not yield the best result in binary. To find out exactly what binary values are being used, one needs a scheme as follows:
| |||