On Fri, 15 Feb 2013 11:47:33 -0800, Gary Herron wrote: > Floating point calculations on a computer (ANY computer, and ANY > programming language) can *never* be expected to be exact!
"never" is incorrect. There are many floating-point calculations which can reasonably be expected be exact[2]. However, multiplying by pi (as in math.radians) isn't such a calculation[1], so radians(90) isn't exactly equal to pi/2 and so cos(radians(90)) isn't exactly equal to zero. [1] It's not so much that the calculation isn't exact, but that the calculation has to use an inexact approximation to pi to start with. [2] In particular, any addition, subtraction, multiplication, division, modulo or square-root calculation for which the correct answer is exactly representable should actually produce the correct answer, exactly. Furthermore, any such calculation for which the correct answer isn't exactly representable should produce the same result as if the correct answer had been calculated to an infinite number of digits then rounded to the nearest representable value according to the current rounding mode. This doesn't apply to transcendental functions (trig, log, exponential), which are subject to the "table maker's dilemma". Typically, the actual result will be one of the two closest representable values to the correct answer, but not necessarily *the* closest. IOW: floating-point arithmetic is deterministic. It follows rules. Not the same rules as real arithmetic, but rules nonetheless. Contrary to common superstition, the least-significant bits are *not* taken from /dev/random. -- http://mail.python.org/mailman/listinfo/python-list
