python math problem

[Dave Angel]

On 02/16/2013 08:55 AM, Nobody wrote:
> 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.
>

Combining two of those rules:   Many years ago I microcoded the decimal 
math package for a machine. Upon checking the value for sin(pi), I was 
considering whether using a different reduction algorithm might get an 
answer closer to zero.  The system used a 13 decimal digit mantissa. 
Imagine my pleasure when I realized that the *second* 13 digits of pi 
were what I was seeing for a result.  (Actually, with a negative sign)

The quantization error of representing pi meant that I was a little 
distance away from 90 degrees, and since the slope of the curve is -1 at 
that point, abs(result) was the first 13 digits of that error.

-- 
DaveA