python math problem
davea at davea.name
Sat Feb 16 19:24:22 CET 2013
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.
> However, multiplying by pi (as in math.radians) isn't such a
> calculation, so radians(90) isn't exactly equal to pi/2 and so
> cos(radians(90)) isn't exactly equal to zero.
>  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.
>  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
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.
More information about the Python-list