Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #38954 > unrolled thread

Re: python math problem

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: python math problem Gary Herron <gherron@digipen.edu> - 2013-02-15 11:47 -0800
    Re: python math problem Nobody <nobody@nowhere.com> - 2013-02-16 13:55 +0000
      Re: python math problem Chris Angelico <rosuav@gmail.com> - 2013-02-17 01:30 +1100
      Re: python math problem Roy Smith <roy@panix.com> - 2013-02-16 09:32 -0500
      Re: python math problem Dave Angel <davea@davea.name> - 2013-02-16 13:24 -0500

#38954 — Re: python math problem

On 02/15/2013 11:39 AM, Kene Meniru wrote:
> I am trying to calculate the coordinates at the end of a line. The length
> and angle of the line are given and I am using the following formula:
>
> x = (math.sin(math.radians(angle)) * length)
> y = (math.cos(math.radians(angle)) * length)
>
> The following are sample answers in the format (x, y) to the given
> length/angle values of the line:
>
> 120/0  = (0.0, 25.0)
> 120/89 = (24.9961923789, 0.436310160932)
> 120/90 = (25.0, 1.53075794228e-15)
> 120/91 = (24.9961923789, -0.436310160932)
>
> Why am I getting a string number instead of the expected answer  for 120/90
> which should be (25.0, 0.0). This happens at all multiples of 90 (i.e. 180
> and 270)
>

Floating point calculations on a computer (ANY computer, and ANY 
programming language) can *never* be expected to be exact!  (Think about 
1/3 , PI, and sqrt(2) for instance.)    The values written out as

1.53075794228e-15

is the (scientific notation) representation of .00000000000000153075794228.  Is that not close enough to zero for your purposes?  (Or is it that you don't understand the 'e-15' portion of the output?)


-- 
Dr. Gary Herron
Department of Computer Science
DigiPen Institute of Technology
(425) 895-4418

[toc] | [next] | [standalone]

#39000

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.

[toc] | [prev] | [next] | [standalone]

#39001

On Sun, Feb 17, 2013 at 12:55 AM, Nobody <nobody@nowhere.com> wrote:
> 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.

That doesn't change the fact that, according to Murphy's Law of
Floating Point Operations, the error will accumulate in one direction
instead of balancing itself out. So while one operation might well
produce the nearest representable value to what you'd expect from real
arithmetic (and I'm not differentiating "real" from "fake" here, but
rather referring to the notion of "real numbers"), multiple sequential
operations will quite probably draw you further and further away. It's
not something to *fear*, just something to understand and manage. It's
no different from estimating by rounding things off, except that a
computer estimates with a tad more precision than a human (since a
computer does *everything* with a tad more precision).

Gratuitous example of ridiculous rounding that still results in a
plausible ball-park figure: "One pound is one kilogram."
http://what-if.xkcd.com/4/

ChrisA

[toc] | [prev] | [next] | [standalone]

#39002

In article <pan.2013.02.16.13.55.31.206000@nowhere.com>,
 Nobody <nobody@nowhere.com> wrote:

> 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.

Unless you're using a Pentium :-)

[toc] | [prev] | [next] | [standalone]

#39008

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web