[Python-ideas] Trigonometry in degrees

[Hugh Fisher]

> Date: Fri, 8 Jun 2018 15:45:31 +1000
> From: Steven D'Aprano <steve at pearwood.info>
> To: python-ideas at python.org
> Subject: Re: [Python-ideas] Trigonometry in degrees
> Message-ID: <20180608054530.GC12683 at ando.pearwood.info>
> Content-Type: text/plain; charset=us-ascii
>
> 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?

Is this going to be backported all the way to Python 2.7?

More generally, there is a huge body of code in C, C++, Java, JavaScript,
etc etc where angles are always passed as radians. Python programmers
will almost certainly have to read, and often write, such code. If everybody
else is doing something in a particular way then there is a strong case for
doing the same thing.

It's not as if Python programmers cannot use degrees. The built in
conversion functions make it easier to do so than most other languages.

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

The degrees and radian functions follow the Python idiom for converting
values, eg str(x) is interpreted as converting x into a str. However the
analogy breaks down because str(x) is a NOP if x is already a string,
while degrees(x) can't tell whether x is already in degrees or not.

Maybe rad2deg would have been better, but the current solution is good
enough - and as noted above, much better than what you get in C or
JavaScript.

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

See above. Why do Python subscripts start from zero? Because most
programmers expect them to.

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

But I want them to be more accurate. I didn't make myself clear. Like you,
I want cos(90 degrees) to be 0, not some small number. Other people have
pointed out the problem with trying to guess the result from the argument
value, so I am suggesting that the functions should instead look at the
calculated result and if it is sufficiently close to 0.0 or 1.0, assume that the
argument value was 90 degrees or some multiple thereof.

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

Well I program using the OpenGL API in Python, so there's at least one
person who will find the d suffix confusing for that reason.

And the d suffix is used for types and functions in OpenGL shading language,
C, ARM/Intel assembler. The intersection with Python programmers may not
be very large, but again it is at least 1. So no they are not utterly unrelated.

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

Is d used as a suffix by mathematicians though? The h works because the
context makes it clear which sense is being used, mathematics, C, or struct
module. Here we are discussing functions in the same module. Whether to
use d or deg is an arbitrary choice for mathematicians (AFAIK), so either
would work equally well. Since d can be confusing for others, to me that
would make deg preferable. But see below where I change my mind.

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

OK, that's interesting, I did not know that. And a quick google shows that
Matlab also has sind and similar variants for degrees.

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

If Julia and Matlab are sufficiently well known, I would prefer d as suffix
rather than prefix.

-- 

        cheers,
        Hugh Fisher