[Python-ideas] Fwd: Trigonometry in degrees

Steven D'Aprano steve at pearwood.info
Mon Jun 11 06:45:24 EDT 2018

On Mon, Jun 11, 2018 at 09:18:22AM +0200, Jacco van Dorp wrote:
> > 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.
> This would basically be the reason for a PiMultiple class - you can
> special case it. You'd know sin(PiMultiple(0.5)) == 0.

Not when I went to school it wasn't. sin(π/2) = sin(90°) = 1.

Perhaps you meant cos?

In any case, the sin function doesn't work that way. Unless we add a 
special dunder method to defer to, it cannot be expected to magically 
know how to deal with these "PiMultiple" objects, except by converting 
them to floats.

You don't suddenly get accurate results by waving a magic wand over the 
float 0.5 and saying "You're a multiple of pi". You still have to code a 
separate algorithm for this, and that's hard work. (Why do you think the 
decimal module doesn't support trig functions?)

Is every function that takes float arguments now supposed to recognise 
PiMultiple objects and treat them specially? How do they integrate in 
the numeric tower and interact with ordinary floats?

But let's say you do this:

def sin(arg):
    if isinstance(arg, PiMultiple):
        # does this mean it needs to be a builtin class?
        call internal sinpi(arg) function
        call regular sin(arg) function

This isn't Java, and not everything needs to be a class. If we go to the 
trouble of writing separate sinpi() etc implementations, why hide one of 
them behind a class (and not even in a proper object-oriented interface) 
when we can just call the functions directly?



I know which I'd rather use.

> It also gives a reason -against- degrees. if you have PiMultiple or
> TauMultiple, it's rather easy to give common angles,

What about the uncommon angles?

The whole point of this proposal is to make it easy to give angles in 
degrees without the need to convert to radians, introducing rounding 
errors over and above those introduced by the trig function itself.

> and students can
> learn to properly learn radians for angles as they should.(because,
> lets be honest, they're objectively better measures of angles than
> degrees, or even *shiver* grads. )

No they are not objectively better measures of angles. With radians, you 
have to divide a right angle into an irrational number of radians, one 
which cannot be expressed in a finite number of decimal places.

In a very real sense, it is impossible to measure exactly 1 radian.

I know that in practical terms, this makes no difference, we can get 
close enough, but physical measurements are limited to rational numbers. 
A measurement system based on irrational numbers, especially one as 
difficult as π, is not objectively better.

Its not just because of tradition that nobody uses radians in civil 
engineering, astronomy, architecture, etc. Radians shine when we're 
doing pure maths and some branches of physics, but they're a PITA to use 
in most practical circumstances.

E,g, the tip of your little finger at arms length is close enough to 1° 
or 0.017 radian. Who wants to measure angles in multiples of 0.017?


Using radians, these heuristics stink.


More information about the Python-ideas mailing list