[Python-ideas] Trigonometry in degrees

[Steven D'Aprano]

On Fri, Jun 08, 2018 at 08:17:02AM +1000, Hugh Fisher wrote:

> But I think that the use of
> radians in programming language APIs is more prevalent, so the initial advantage
> of easy learning will be outweighed by the long term inconvenience of
> adjusting to what everyone else is doing.

But why would you need to?

If we had a degrees API, why wouldn't people just use it?


> Writing degrees(x) and radians(x) is a little inconvenient, but it
> does make it clear what units are being used.

I never know what conversion function to use. I always expect something 
like deg2rad and rad2deg. I never remember whether degrees(x) expects an 
angle in degrees or returns an angle in degrees.

So I would disagree that it is clear.


> And even if your proposal is adopted, there is still going
> to be a lot of code around that uses the older math routines.

Why would that be a problem?

When the iterator protocol was introduced, that didn't require lists and 
sequences to be removed.


> Not just young students :-) I agree with this, but I would prefer the 
> check to be in the implementation of the existing functions as well. 
> Any sin/cos very close to 0 becomes 0, any close to 1 becomes 1.

Heavens no! That's a terrible idea -- that means that functions which 
*ought to return 0.9999987 (say) will suddenly become horribly 
inaccurate and return 1.

The existing trig functions are as close to accurate as is practical to 
expect with floating point maths. (Although some platform's maths 
libraries are less accurate than others.) We shouldn't make them *less* 
accurate just because some people don't care for more than three decimal 
places.


> > - Standard names will be chosen so that everyone will use the same 
> > name convention. I suggest adding a "d" like sind, cosd, tand, 
> > acosd, asind, atand, atan2d.
> 
> Not "d". In the OpenGL 3D API, and many 3D languages/APIs since, appending "d"
> means "double precision".

Python floats are already double precision.

What advantage is there for reserving a prefix/suffix because some 
utterly unrelated framework in another language uses it for a completely 
different purpose?

Like mathematicians, we use the "h" suffix for hyperbolic sin, cos and 
tan; should we have done something different because C uses ".h" for 
header files, or because the struct module uses "h" as the format code 
for short ints?

Julia provides a full set of trigonometric functions in both radians and 
degrees:

https://docs.julialang.org/en/release-0.4/manual/mathematical-operations/#trigonometric-and-hyperbolic-functions

They use sind, cosd, tand etc for the variants expecting degrees. I 
think that's much more relevant than OpenGL.

Although personally I prefer the look of d as a prefix:

dsin, dcos, dtan

That's more obviously pronounced "d(egrees) sin" etc rather than "sined" 
"tanned" etc.


-- 
Steve