<div dir="auto"><div>- I didn't know there were sinf in C (that's since C99), I was aware of the 'd' postfix in opengl.<div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><br></div><div dir="auto">By the way I've seen a stackoverflow answer using Sin and Cos with a capital letter, doesn't seem very explicit to me.</div><div dir="auto"><br></div><div dir="auto">- 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).</div><div dir="auto"><br></div><div dir="auto">- 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.</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">Let's notice there are some libraries that wrap units so that one can mix them safely (and avoid to add meters to seconds).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">- 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.</div><div dir="auto"><br></div><div dir="auto">- 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.</div><div dir="auto"><br></div>- 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.</div><div dir="auto"><br></div><div dir="auto">- 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).<br><br><div class="gmail_quote" dir="auto"><div dir="ltr">Le ven. 8 juin 2018 à 00:17, Hugh Fisher <<a href="mailto:hugo.fisher@gmail.com" rel="noreferrer noreferrer" target="_blank">hugo.fisher@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Date: Thu, 7 Jun 2018 12:33:29 +0000<br>
> From: Robert Vanden Eynde <<a href="mailto:robertvandeneynde@hotmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">robertvandeneynde@hotmail.com</a>><br>
> To: python-ideas <<a href="mailto:python-ideas@python.org" rel="noreferrer noreferrer noreferrer" target="_blank">python-ideas@python.org</a>><br>
> Subject: [Python-ideas] Trigonometry in degrees<br>
> Message-ID:<br>
> ><br>
> I suggest adding degrees version of the trigonometric functions in the math module.<br>
><br>
> - Useful in Teaching and replacing calculators by python, importing something is seen by the young students much more easy than to define a function.<br>
<br>
I agree that degrees are useful for teaching. They are also very<br>
useful for graphics<br>
programming, especially with my favourite OpenGL API. But I think that<br>
the use of<br>
radians in programming language APIs is more prevalent, so the initial advantage<br>
of easy learning will be outweighed by the long term inconvenience of<br>
adjusting to<br>
what everyone else is doing.<br>
<br>
Writing degrees(x) and radians(x) is a little inconvenient, but it<br>
does make it clear<br>
what units are being used. And even if your proposal is adopted, there<br>
is still going<br>
to be a lot of code around that uses the older math routines. With the<br>
current API<br>
it is a least safe to assume that angles are radians unless stated otherwise.<br>
<br>
> - 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<br>
><br>
> 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.<br>
<br>
Not just young students :-) I agree with this, but I would prefer the<br>
check to be in<br>
the implementation of the existing functions as well. Any sin/cos very<br>
close to 0<br>
becomes 0, any close to 1 becomes 1.<br>
<br>
> - 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.<br>
<br>
Not "d". In the OpenGL 3D API, and many 3D languages/APIs since, appending "d"<br>
means "double precision". It's even sort of implied by the C math<br>
library which has<br>
sinf and friends for single precision.<br>
<br>
><br>
> 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.<br>
<br>
Agree, not a good idea.<br>
<br>
-- <br>
<br>
cheers,<br>
Hugh Fisher<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" rel="noreferrer noreferrer noreferrer" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div></div></div>