[Python-ideas] Fwd: Trigonometry in degrees

Steven D'Aprano steve at pearwood.info
Mon Jun 11 01:48:31 EDT 2018


On Sun, Jun 10, 2018 at 10:01:09PM -0700, Chris Barker via Python-ideas wrote:

> In regard to the "special values", and exact results -- a good math lib
> should return results that are "exact" in all but maybe the last digit
> stored. So you could check inputs and outputs with, e.g. math.isclose() to
> give people the "exact" results. -- and keep it all in floating point.

I wish Uncle Timmy or Mark Dickinson were around to give a definite 
answer, but in their absence I'll have a go. I'm reasonably sure 
that's wrong.

The problem with trig functions is that they suffer from "the 
table maker's dilemma", so it is very hard to guarantee a correctly 
rounded result without going to ludicrous extremes:

http://perso.ens-lyon.fr/jean-michel.muller/Intro-to-TMD.htm

So I think that there's no guarantee given for trancendental functions 
like sine, cosine etc.

But even if they were, using isclose() is the wrong solution. Suppose 
sin(x) returns some number y, such that isclose(y, 0.0) say. You have no 
way of knowing that y is an inaccurate result that ought to be zero, or 
whether the answer should be non-zero and y is correct. You cannot 
assume that "y is close to zero, therefore it ought to be zero".

It's not just zero, the same applies for any value. That's just moving 
rounding errors from one input to a slightly different input.

# current situation
sine of x returns y, but the mathematical exact result is exactly z

# suggested "fix"
sine of x ± a tiny bit returns exactly z, but ought to return y

Guessing what sin or cos "ought to" return based on either the inexact 
input or inexact output is not a good approach.

Remember, because π is irrational, we cannot actually call sin or cos on 
any rational multiple of π. We can only operate on multiples of pi, 
which is *close to* but not the same as π. That's why it is okay that 
tan(pi/2) returns a huge number instead of infinity or NAN. That's 
because the input is every so slightly smaller than π/2. That's exactly 
the behaviour you want when x is ever so slightly smaller than π/2.


-- 
Steve


More information about the Python-ideas mailing list