[Python-ideas] Trigonometry in degrees

[Richard Damon]

On 6/7/18 7:08 PM, Robert Vanden Eynde wrote:
> - I didn't know there were sinf in C (that's since C99), I was aware
> of the 'd' postfix in opengl.
>
> So yeah, sind would be a bad idea, but sindeg or degsin would be too
> long, hmm, and I can settle for the Pre or Post fix. sindeg(90)
> degsin(90) are both pretty, the first emphasize on the "degree" part
> and the second on the "sin(90)" part. I feel I prefer sindeg, cosdeg,
> atandeg, atan2deg, phasedeg, rectdeg hmhm
>
> By the way I've seen a stackoverflow answer using Sin and Cos with a
> capital letter, doesn't seem very explicit to me.
>
> - I could do a pypi for it for sure, I didn't know it was that easy to
> create a repo actually. degreesmath (and degreesmath.cmath ?) would be
> a good package name but again I don't want to name the functions sin,
> cos. People could rename them on import anyway (let the fools be fools
> as long as they don't hurt anyone).
>
> - I agree radians should be the default, but is it especially Because
> sin/cos must be in radians ? And because it's more efficient ? The
> problem arrises when Mixing units in the same program.
>
> However, should everyone use m³ and not Liters because they're the SI
> units ? That's more a problems of "mixing units and not sticking to
> one convention". I've seen lot of libraries using degrees (and not
> just good old glRotate).
>
> Let's notice there are some libraries that wrap units so that one can
> mix them safely (and avoid to add meters to seconds).
>
> Let's be honest, radians are useful only when converting arc length,
> areas or dealing with derivatives, signals, or complex numbers
> (engineering stuffs), and efficiency of sin/cos implementations. When
> doing simple 2D/3D applications, angles are just angles and nobody
> needs to know that derivative of sin(ax) is a·cos(ax) if x is in radians.
>
> - Integers are more convenient than float, you could add 1 degree
> every frame at 60fps to a counter and after 60 frames you'll do a full
> turn, adding tau/360 doesn't add so well (floating point
> representation). Having exact representation for multiple of 90
> degrees is a big plus. Another advantage is also being able to check
> if the angle is particular (multiple of 30 or 90 for example).
> Especially python Integers with infinite precision.
>
> - Everyone knows degrees, whereas radians are known only by people
> that had math in 10th grade. I know it's easy to say "just convert"
> but trust me, not everyone is confident with unit conversions, when
> you ask "what's the unit of angle ?" people will think of degrees.
>
> - Changing the behavior for current cos/sin function to have cos(pi/2)
> being exact is a bad idea in my opinion, the good old sin/cos from C
> exist for a long time and people rely on the behaviors. That would
> break too much existing code for no much trouble. And would slow
> Current applications relying on the efficiency of the C functions.
>
> - I totally agree writing degrees(...) and radians(...) make it clear
> and explicit. That's why I strongly discourage people defining their
> own "sin" function that'd take degrees, therefore I look for a new
> function name (sindeg).
First I feel the need to point out that radians are actually fairly
fundamental in trigonometry, so there is good reasons for the base
functions to be based on radians. The fact that the arc length of the
angle on the unit circle is the angle in radians actually turns out to
be a fairly basic property.

To make it so that sindeg/cosdeg of multiples of 90 come out exact is
probably easiest to do by doing the angle reduction in degrees (so the
nice precise angles stay as nice precise angles) and then either adjust
the final computation formulas for degrees, or convert the angle to
radians and let the fundamental routine do the small angle computation.

While we are at it, it might be worth thinking if it might make sense to
also define a set of functions using circles as a unit (90 degrees =
0.25, one whole revolution = 1)

-- 
Richard Damon