[Python-ideas] Trigonometry in degrees

[Robert Vanden Eynde]

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

Le ven. 8 juin 2018 à 00:17, Hugh Fisher <hugo.fisher at gmail.com> a écrit :

> > Date: Thu, 7 Jun 2018 12:33:29 +0000
> > From: Robert Vanden Eynde <robertvandeneynde at hotmail.com>
> > To: python-ideas <python-ideas at python.org>
> > Subject: [Python-ideas] Trigonometry in degrees
> > Message-ID:
> >         >
> > I suggest adding degrees version of the trigonometric functions in the
> math module.
> >
> > - Useful in Teaching and replacing calculators by python, importing
> something is seen by the young students much more easy than to define a
> function.
>
> I agree that degrees are useful for teaching. They are also very
> useful for graphics
> programming, especially with my favourite OpenGL API. 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.
>
> Writing degrees(x) and radians(x) is a little inconvenient, but it
> does make it clear
> what units are being used. And even if your proposal is adopted, there
> is still going
> to be a lot of code around that uses the older math routines. With the
> current API
> it is a least safe to assume that angles are radians unless stated
> otherwise.
>
> > - Special values could be treated, aka when the angle is a multiple of
> 90, young students are often surprise to see that cos(pi/2) != 0
> >
> > Testing for a special value Isn't very costly (x % 90 == 0) but it could
> be pointed out that there is a small overhead using the "degrees"
> equivalent of trig function because of the radians to degrees conversion
> And the special values testing.
>
> 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.
>
> > - 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". It's even sort of implied by the C math
> library which has
> sinf and friends for single precision.
>
> >
> > Creating a new package like 'from math.degrees import cos' however I
> would not recommend that because "cos" in the source code would mean to
> lookup the import to know if it's in degrees or radians (and that leads to
> very filthy bugs). Also "degrees" is already so the name would have to
> change the name of the package.
>
> Agree, not a good idea.
>
> --
>
>         cheers,
>         Hugh Fisher
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180608/8af34f6f/attachment.html>