python math problem

[Nobody]

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.