Re: [Pythonideas] Trigonometry in degrees
Date: Thu, 7 Jun 2018 12:33:29 +0000 From: Robert Vanden Eynde
To: pythonideas Subject: [Pythonideas] Trigonometry in degrees MessageID: > 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
 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
Date: Thu, 7 Jun 2018 12:33:29 +0000 From: Robert Vanden Eynde
To: pythonideas Subject: [Pythonideas] Trigonometry in degrees MessageID: > 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 _______________________________________________ Pythonideas mailing list Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
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
Richard Damon writes:
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.
You would still need some sort of correction for many angles because of the nature of floating point computation. The modern approach is that floating point is exact computation but some numbers can't be exactly represented. Since Pi is irrational, Pi/4 is too, so it definitely cannot be represented. Making a correction to a number that "looks like" Pi/4 is against this philosophy. So you need separate functions (a "high school mode" argument would be frowned upon, I think).
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)
While 1/4 is no problem, 1/6 is not exactly representable as a binary floating point number, and that's kind of an important angle for high school trigonometry (which is presumably what we're talking about here  a symbolic math program would not represent Pi by a floating point number, but rather as a symbol with special properties as an argument to a trigonometric function!) My bias is that people who want to program this kind of thing just need to learn about floating point numbers and be aware that they're going to have to accept that
from math import cos, radians cos(radians(90)) 6.123233995736766e17
is good enough for government work, including at the local public high school. Of course, I admit that's a bias, not a scientific fact. :)  Associate Professor Division of Policy and Planning Science http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 0298535175 Tennodai 111, Tsukuba 3058573 JAPAN
On Thu, Jun 7, 2018 at 10:38 PM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
6.123233995736766e17
is good enough for government work, including at the local public high school.
There probably is room for a library like "fractions" that represents multiples of pi or degrees precisely. I'm not sure how complicated or valuable of an endeavor that would be. But while I agree that floating point is good enough, we probably can do better.
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/release0.4/manual/mathematicaloperations/#tr... 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
On Fri, Jun 8, 2018 at 3:45 PM, Steven D'Aprano
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.
Having it as a suffix does have one advantage. The math module would need a hyperbolic sine function which accepts an argument in; and then, like Charles Napier [1], Python would finally be able to say "I have sindh". ChrisA [1] Apocryphally, alas.
On Thu, Jun 07, 2018 at 10:39:06PM 0400, Richard Damon wrote:
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.
People managed to use trigonometry for *literally* millennia before radians were invented and named by James Thomson in 1873. Just because they are, *in some sense*, mathematically fundamental doesn't mean we ought to be using them for measurements. We don't write large numbers using powers of e instead of powers of 10, just because exponentiation to base e is in some sense more fundamental than other powers. Even the fact that we talk about sine, cosine and tangent as distinct functions is mathematically unnecessary, since both cosine and tangent can be expressed in terms of sine.
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)
Hardly anyone still uses grads, and even fewer people use revolutions as the unit of angles. But if you did need revolutions, conveniently many simple fractions of a revolution come out to be whole numbers of degrees, thanks to 360 having lots of factors. All of these fractions of a revolution are exact whole numbers of degrees: 1/2, 1/3, 1/4, 1/5, 1/6, 1/8, 1/9, 1/10, 1/12, 1/15, 1/18 so I don't believe we need a third set of trig functions for revolutions.  Steve
On Fri, Jun 08, 2018 at 02:37:33PM +0900, Stephen J. Turnbull wrote:
My bias is that people who want to program this kind of thing just need to learn about floating point numbers and be aware that they're going to have to accept that
from math import cos, radians cos(radians(90)) 6.123233995736766e17
is good enough for government work, including at the local public high school.
In Australia, most secondary schools recommend or require CAS calculators from about Year 10, sometimes even from Year 9. Most (all?) state curricula for Year 11 and 12 mandate CAS calculators. Even oldschool scientific calcuators without the fancy CAS symbolic maths are capable of having cos(90) return zero in degree mode. It is quite common for high school students to expect cos(90°) to come out as exactly zero. And why not? It's the 21st century, not 1972 when fourfunction calculators were considered advanced technology :) To my mind, the question is not "should we have trig functions that take angles in degrees"  that's a nobrainer, of course we should. The only questions in my mind are whether or not such a library is (1) appropriate for the stdlib and (2) ready for the stdlib.  Steve
Stephen J. Turnbull wrote:
Since Pi is irrational, Pi/4 is too, so it definitely cannot be represented. Making a correction to a number that "looks like" Pi/4 is against this philosophy.
I'm not sure what all the fuss is about:
from math import pi, sin sin(pi/2) 1.0 sin(pi/2 + 2 * pi) 1.0 sin(pi/2 + 4 * pi) 1.0 sin(pi/2 + 8 * pi) 1.0 sin(pi/2 + 16 * pi) 1.0 sin(pi/2 + 32 * pi) 1.0
Seems to be more than good enough for most angle ranges that your average schoolkid is going to be plugging into it. In fact you have to go quite a long way before expectations start to break down:
sin(pi/2 + 10000000 * pi) 1.0 sin(pi/2 + 100000000 * pi) 0.9999999999999984
 Greg
Chris Angelico wrote:
The math module would need a hyperbolic sine function which accepts an argument in;
Except that the argument to hyperbolic trig functions is not an angle in any normal sense of the word, so expressing it in degrees makes little sense. (However I do like the idea of a function called "tanhd" and pronounced "tanned hide". :)  Greg
Steven D'Aprano wrote:
Even oldschool scientific calcuators without the fancy CAS symbolic maths are capable of having cos(90) return zero in degree mode.
FWIW, my Casio fx100 (over 30 years old) produces exactly 1 for both sin(90°) and sin(pi/2) for its version of pi.  Greg
On Fri, Jun 08, 2018 at 03:55:34PM +1000, Chris Angelico wrote:
On Fri, Jun 8, 2018 at 3:45 PM, Steven D'Aprano
wrote: 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.
Having it as a suffix does have one advantage. The math module would need a hyperbolic sine function which accepts an argument in; and then, like Charles Napier [1], Python would finally be able to say "I have sindh".
Ha ha, nice pun, but no, the hyperbolic trig functions never take arguments in degrees. Or radians for that matter. They are "hyperbolic angles", which some electrical engineering text books refer to as "hyperbolic radians", but all the maths text books I've seen don't call them anything other than a real number. (Or sometimes a complex number.) But for what it's worth, there is a correspondence of a sort between the hyperbolic angle and circular angles. The circular angle going between 0 to 45° corresponds to the hyperbolic angle going from 0 to infinity. https://en.wikipedia.org/wiki/Hyperbolic_angle https://en.wikipedia.org/wiki/Hyperbolic_function
[1] Apocryphally, alas.
Don't ruin a good story with facts ;)  Steve
Or when students get stuff e17 out of a function, you teach them what floating point numbers are and what gotcha's they can expect. The simple version is "value is stored as a float, and a float gets rounding errors below e16", or for the more inquisitive minds you give them nice places like https://docs.python.org/3/tutorial/floatingpoint.html . If they're really going to use what they learn, they're going to run into it sooner or later. So having a bit of base knowledge about floats is a lot more useful than having to google "why does sin() return weird values python". At the very least, they'll isntead google "float limitations", which is going to get them a lot closer to the real information a lot faster. That said, I wouldn't be that opposed to a dedicated type to remember things about pi. Lets say.... class pi(Numeric): """Represents numbers that represent some function of pi""" def __init__(self, mul=1): self.multiplier = mul def __mul__(self, other): if isinstance(other, Numeric): return self.__class__(self.multiplier*other) (similar with the other special methods) (Please consider the idea, not the exact code. I dont even know if i spelled the numeric superclass right. Let alone making this type hashable and immutable, which it should be.) It's probably not a good idea to use that for performancecritical parts, but for the more trivial applications, it could allow for more clarity. Also, in a lot of common angles, it'd be far easier to actually recognize special cases. you could also make it __repr__ like f"Pi*{self.multiplier}", so you get a neat exact answer if you print it..
 Thanks for pointing out a language (Julia) that already had a name convention. Interestingly they don't have a atan2d function. Choosing the same convention as another language is a big plus.
 Adding trig function using floats between 0 and 1 is nice, currently one needs to do sin(tau * t) which is not so bad (from math import tau, tau sounds like turn).
 Julia has sinpi for sin(pi*x), one could have sintau(x) for sin(tau*x) or sinturn(x).
Grads are in the idea of turns but with more problems, as you guys said, grads are used by noone, but turns are more useful. sin(tau * t) For The Win.
 Even though people mentionned 1/6 not being exact, so that advantage over radians isn't that obvious ?
from math import sin, tau
from fractions import Fraction
sin(Fraction(1,6) * tau)
sindeg(Fraction(1,6) * 360)
These already work today by the way.
 As you guys pointed out, using radians implies knowing a little bit about floating point arithmetic and its limitations. Integer are more simple and less error prone. Of course it's useful to know about floats but in many case it's not necessary to learn about it right away, young students just want their player in the game move in a straight line when angle = 90.
 sin(pi/2) == 1 but cos(pi/2) != 0 and sin(3*pi/2) != 1 so sin(pi/2) is kind of an exception.
Le ven. 8 juin 2018 à 09:11, Steven D'Aprano
On Fri, Jun 8, 2018 at 3:45 PM, Steven D'Aprano
mailto:steve@pearwood.info> wrote: 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.
Having it as a suffix does have one advantage. The math module would need a hyperbolic sine function which accepts an argument in; and then, like Charles Napier [1], Python would finally be able to say "I have sindh".
Ha ha, nice pun, but no, the hyperbolic trig functions never take arguments in degrees. Or radians for that matter. They are "hyperbolic angles", which some electrical engineering text books refer to as "hyperbolic radians", but all the maths text books I've seen don't call them anything other than a real number. (Or sometimes a complex number.) But for what it's worth, there is a correspondence of a sort between the hyperbolic angle and circular angles. The circular angle going between 0 to 45° corresponds to the hyperbolic angle going from 0 to infinity. https://en.wikipedia.org/wiki/Hyperbolic_angle https://en.wikipedia.org/wiki/Hyperbolic_function
[1] Apocryphally, alas.
Don't ruin a good story with facts ;)  Steve _______________________________________________ Pythonideas mailing list Pythonideas@python.orgmailto:Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, Jun 08, 2018 at 06:34:25PM +1200, Greg Ewing wrote:
I'm not sure what all the fuss is about:
from math import pi, sin sin(pi/2) 1.0
Try cos(pi/2) or sin(pi/6). Or try: sin(pi/4) == sqrt(2)/2 tan(pi/4) == 1 tan(pi/3) == sqrt(3) And even tan(pi/2), which ought to be an error, but isn't. These are, of course, limitations due to the finite precision of floats. But Julia gets the equivalent degreebased calculations all correct, except for tan(90) where it returns Inf (NAN would be better, as the limit from below and the limit from above are different).  Steve
On 20180608 01:44, Yuval Greenfield wrote:
On Thu, Jun 7, 2018 at 10:38 PM Stephen J. Turnbull
mailto:turnbull.stephen.fw@u.tsukuba.ac.jp> wrote: 6.123233995736766e17 >>>
is good enough for government work, including at the local public high school.
There probably is room for a library like "fractions" that represents multiples of pi or degrees precisely. I'm not sure how complicated or valuable of an endeavor that would be. But while I agree that floating point is good enough, we probably can do better.
Yes, I agree with making a module (called `rational_trig`?), that defines some Angle constants, and defines trig functions that accept Angle objects. Using angle objects will prevent the explosion of unitspecific variations on the trig functions (sin, sindeg, singrad, etc). Like mentioned above, the Angle object is probably best implemented as a Rational of 2*pi, which will allow our favorite angles to be represented without floating point error. We can define `degrees` and `radians` constants which can be used as units; then trig looks something like: from rational_trig import cos if cos(90*degrees) == 0: print("yay!") It is probably slow as molasses, but maybe good enough for a teaching environment?
On Fri, Jun 08, 2018 at 08:45:54AM +0000, Robert Vanden Eynde wrote:
from math import sin, tau from fractions import Fraction sin(Fraction(1,6) * tau) sindeg(Fraction(1,6) * 360)
These already work today by the way.
You obviously have a different understanding of the words "already work" than I do: py> sindeg(Fraction(1,6) * 360) Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'sindeg' is not defined Since tau is a float, writing Fraction(1,6) * tau instead of tau/6 is a waste of time. Also, Fraction(1,6) * 360 is also a waste of time, since 360/6 is not only exact, but can be done at compiletime.  Steve
# Python, NumPy, SymPy, mpmath, sage trigonometric functions
https://en.wikipedia.org/wiki/Trigonometric_functions
## Python math module
https://docs.python.org/3/library/math.html#trigonometricfunctions
 degrees(radians): Float degrees
 radians(degrees): Float degrees
## NumPy
https://docs.scipy.org/doc/numpy/reference/routines.math.html#trigonometric...
 degrees(radians) : List[float] degrees
 rad2deg(radians): List[float] degrees
 radians(degrees) : List[float] radians
 deg2rad(degrees): List[float] radians
https://docs.scipy.org/doc/numpy/reference/generated/numpy.sin.html
## SymPy
http://docs.sympy.org/latest/modules/functions/elementary.html#sympyfunctio...
http://docs.sympy.org/latest/modules/functions/elementary.html#trionometric...
 sympy.mpmath.degrees(radians): Float degrees
 sympy.mpmath.radians(degrees): Float radians
 https://stackoverflow.com/questions/31072815/cosdandsindwithsympy
 cosd, sind

https://stackoverflow.com/questions/31072815/cosdandsindwithsympy#commen...
> Let x, theta, phi, etc. be Symbols representing quantities in
radians. Keep a list of these symbols: angles = [x, theta, phi]. Then, at
the very end, use y.subs([(angle, angle*pi/180) for angle in angles]) to
change the meaning of the symbols to degrees"
## mpmath
http://mpmath.org/doc/current/functions/trigonometric.html
 sympy.mpmath.degrees(radians): Float degrees
 sympy.mpmath.radians(degrees): Float radians
## Sage
https://doc.sagemath.org/html/en/reference/functions/sage/functions/trig.htm...
On Friday, June 8, 2018, Robert Vanden Eynde
 Thanks for pointing out a language (Julia) that already had a name convention. Interestingly they don't have a atan2d function. Choosing the same convention as another language is a big plus.
 Adding trig function using floats between 0 and 1 is nice, currently one needs to do sin(tau * t) which is not so bad (from math import tau, tau sounds like turn).
 Julia has sinpi for sin(pi*x), one could have sintau(x) for sin(tau*x) or sinturn(x).
Grads are in the idea of turns but with more problems, as you guys said, grads are used by noone, but turns are more useful. sin(tau * t) For The Win.
 Even though people mentionned 1/6 not being exact, so that advantage over radians isn't that obvious ?
from math import sin, tau from fractions import Fraction sin(Fraction(1,6) * tau) sindeg(Fraction(1,6) * 360)
These already work today by the way.
 As you guys pointed out, using radians implies knowing a little bit about floating point arithmetic and its limitations. Integer are more simple and less error prone. Of course it's useful to know about floats but in many case it's not necessary to learn about it right away, young students just want their player in the game move in a straight line when angle = 90.
 sin(pi/2) == 1 but cos(pi/2) != 0 and sin(3*pi/2) != 1 so sin(pi/2) is kind of an exception.
Le ven. 8 juin 2018 à 09:11, Steven D'Aprano
a écrit : On Fri, Jun 08, 2018 at 03:55:34PM +1000, Chris Angelico wrote:
On Fri, Jun 8, 2018 at 3:45 PM, Steven D'Aprano
wrote: 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.
Having it as a suffix does have one advantage. The math module would need a hyperbolic sine function which accepts an argument in; and then, like Charles Napier [1], Python would finally be able to say "I have sindh".
Ha ha, nice pun, but no, the hyperbolic trig functions never take arguments in degrees. Or radians for that matter. They are "hyperbolic angles", which some electrical engineering text books refer to as "hyperbolic radians", but all the maths text books I've seen don't call them anything other than a real number. (Or sometimes a complex number.)
But for what it's worth, there is a correspondence of a sort between the hyperbolic angle and circular angles. The circular angle going between 0 to 45° corresponds to the hyperbolic angle going from 0 to infinity.
https://en.wikipedia.org/wiki/Hyperbolic_angle
https://en.wikipedia.org/wiki/Hyperbolic_function
[1] Apocryphally, alas.
Don't ruin a good story with facts ;)
 Steve _______________________________________________ Pythonideas mailing list Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
On 6/8/18 01:45, Robert Vanden Eynde wrote:
 Thanks for pointing out a language (Julia) that already had a name convention. Interestingly they don't have a atan2d function. Choosing the same convention as another language is a big plus.
For what it's worth, scipy calls them sindg, cosdg, tandg, cotdg. https://docs.scipy.org/doc/scipy1.1.0/reference/special.html  Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth."  Umberto Eco
On Fri, Jun 8, 2018 at 11:44 PM Robert Kern
On 6/8/18 01:45, Robert Vanden Eynde wrote:
 Thanks for pointing out a language (Julia) that already had a name convention. Interestingly they don't have a atan2d function. Choosing the same convention as another language is a big plus.
For what it's worth, scipy calls them sindg, cosdg, tandg, cotdg.
https://docs.scipy.org/doc/scipy1.1.0/reference/special.html
## SciPy https://docs.scipy.org/doc/scipy1.1.0/reference/special.html#conveniencefu...  https://docs.scipy.org/doc/scipy1.1.0/reference/generated/scipy.special.sin...
 Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth."  Umberto Eco
_______________________________________________ Pythonideas mailing list Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
Indeed what we need for exact math for multiple of 90 (and 30) is ideas from the symbolic libraries (sympy, sage).
Of course the symbolic lib can do more like :
sage: k = var('k', domain='integer')
sage: cos(1 + 2*k*pi)
cos(1)
sage: cos(k*pi)
cos(pi*k)
sage: cos(pi/3 + 2*k*pi)
1/2
But that would concern symbolic lib only I think.
For the naming convention, scipy using sindg (therefore Nor sind nor sindeg) will make the sind choice less obvious. However if Matlab and Julia chooses sind that's a good path to go, Matlab is pretty popular, as other pointed out, with Universities giving "free" licences and stuff. With that regards, scipy wanting to "be a replacement to Matlab in python and open source" it's interesting they chose sindg and not the Matlab name sind.
For the "d" as suffix that would mean "d" as "double" like in opengl. Well, let's remember that in Python there's only One floating type, that's a double, and it's called float... So python programmers will not think "sind means it uses a python float and not a python float32 that C99 sinf would". Python programmers would be like "sin takes float in radians, sind takes float in degrees or int, because int can be converted to float when there's no overflow".
Le sam. 9 juin 2018 à 04:09, Wes Turner
On Fri, Jun 8, 2018 at 3:45 PM, Steven D'Aprano
mailto:steve@pearwood.info> wrote: 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.
Having it as a suffix does have one advantage. The math module would need a hyperbolic sine function which accepts an argument in; and then, like Charles Napier [1], Python would finally be able to say "I have sindh".
Ha ha, nice pun, but no, the hyperbolic trig functions never take arguments in degrees. Or radians for that matter. They are "hyperbolic angles", which some electrical engineering text books refer to as "hyperbolic radians", but all the maths text books I've seen don't call them anything other than a real number. (Or sometimes a complex number.) But for what it's worth, there is a correspondence of a sort between the hyperbolic angle and circular angles. The circular angle going between 0 to 45° corresponds to the hyperbolic angle going from 0 to infinity. https://en.wikipedia.org/wiki/Hyperbolic_angle https://en.wikipedia.org/wiki/Hyperbolic_function
[1] Apocryphally, alas.
Don't ruin a good story with facts ;)  Steve _______________________________________________ Pythonideas mailing list Pythonideas@python.orgmailto:Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Pythonideas mailing list Pythonideas@python.orgmailto:Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
I think this suggestion should result in a library on PyPi, which can then be considered for the standard library if it sees a lot of use. Also, modern OpenGL does this just like Python does: all of the trigonometric functions take radians and a "radians" function is provided. Best, Neil On Saturday, June 9, 2018 at 2:55:12 PM UTC4, Robert Vanden Eynde wrote:
Indeed what we need for exact math for multiple of 90 (and 30) is ideas from the symbolic libraries (sympy, sage).
Of course the symbolic lib can do more like :
sage: k = var('k', domain='integer') sage: cos(1 + 2*k*pi) cos(1) sage: cos(k*pi) cos(pi*k) sage: cos(pi/3 + 2*k*pi) 1/2
But that would concern symbolic lib only I think.
For the naming convention, scipy using sindg (therefore Nor sind nor sindeg) will make the sind choice less obvious. However if Matlab and Julia chooses sind that's a good path to go, Matlab is pretty popular, as other pointed out, with Universities giving "free" licences and stuff. With that regards, scipy wanting to "be a replacement to Matlab in python and open source" it's interesting they chose sindg and not the Matlab name sind.
For the "d" as suffix that would mean "d" as "double" like in opengl. Well, let's remember that in Python there's only One floating type, that's a double, and it's called float... So python programmers will not think "sind means it uses a python float and not a python float32 that C99 sinf would". Python programmers would be like "sin takes float in radians, sind takes float in degrees or int, because int can be converted to float when there's no overflow".
Le sam. 9 juin 2018 à 04:09, Wes Turner
javascript:> a écrit : # Python, NumPy, SymPy, mpmath, sage trigonometric functions https://en.wikipedia.org/wiki/Trigonometric_functions
## Python math module https://docs.python.org/3/library/math.html#trigonometricfunctions  degrees(radians): Float degrees  radians(degrees): Float degrees
## NumPy
https://docs.scipy.org/doc/numpy/reference/routines.math.html#trigonometric...  degrees(radians) : List[float] degrees  rad2deg(radians): List[float] degrees  radians(degrees) : List[float] radians  deg2rad(degrees): List[float] radians
https://docs.scipy.org/doc/numpy/reference/generated/numpy.sin.html
## SymPy
http://docs.sympy.org/latest/modules/functions/elementary.html#sympyfunctio...
http://docs.sympy.org/latest/modules/functions/elementary.html#trionometric...
 sympy.mpmath.degrees(radians): Float degrees  sympy.mpmath.radians(degrees): Float radians
 https://stackoverflow.com/questions/31072815/cosdandsindwithsympy  cosd, sind  https://stackoverflow.com/questions/31072815/cosdandsindwithsympy#commen...
> Let x, theta, phi, etc. be Symbols representing quantities in radians. Keep a list of these symbols: angles = [x, theta, phi]. Then, at the very end, use y.subs([(angle, angle*pi/180) for angle in angles]) to change the meaning of the symbols to degrees"
## mpmath http://mpmath.org/doc/current/functions/trigonometric.html  sympy.mpmath.degrees(radians): Float degrees  sympy.mpmath.radians(degrees): Float radians
## Sage
https://doc.sagemath.org/html/en/reference/functions/sage/functions/trig.htm...
On Friday, June 8, 2018, Robert Vanden Eynde
javascript:> wrote:  Thanks for pointing out a language (Julia) that already had a name convention. Interestingly they don't have a atan2d function. Choosing the same convention as another language is a big plus.
 Adding trig function using floats between 0 and 1 is nice, currently one needs to do sin(tau * t) which is not so bad (from math import tau, tau sounds like turn).
 Julia has sinpi for sin(pi*x), one could have sintau(x) for sin(tau*x) or sinturn(x).
Grads are in the idea of turns but with more problems, as you guys said, grads are used by noone, but turns are more useful. sin(tau * t) For The Win.
 Even though people mentionned 1/6 not being exact, so that advantage over radians isn't that obvious ?
from math import sin, tau from fractions import Fraction sin(Fraction(1,6) * tau) sindeg(Fraction(1,6) * 360)
These already work today by the way.
 As you guys pointed out, using radians implies knowing a little bit about floating point arithmetic and its limitations. Integer are more simple and less error prone. Of course it's useful to know about floats but in many case it's not necessary to learn about it right away, young students just want their player in the game move in a straight line when angle = 90.
 sin(pi/2) == 1 but cos(pi/2) != 0 and sin(3*pi/2) != 1 so sin(pi/2) is kind of an exception.
Le ven. 8 juin 2018 à 09:11, Steven D'Aprano
javascript:> a écrit : On Fri, Jun 08, 2018 at 03:55:34PM +1000, Chris Angelico wrote:
On Fri, Jun 8, 2018 at 3:45 PM, Steven D'Aprano
javascript:> wrote: 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.
Having it as a suffix does have one advantage. The math module would need a hyperbolic sine function which accepts an argument in; and then, like Charles Napier [1], Python would finally be able to say "I have sindh".
Ha ha, nice pun, but no, the hyperbolic trig functions never take arguments in degrees. Or radians for that matter. They are "hyperbolic angles", which some electrical engineering text books refer to as "hyperbolic radians", but all the maths text books I've seen don't call them anything other than a real number. (Or sometimes a complex number.)
But for what it's worth, there is a correspondence of a sort between the hyperbolic angle and circular angles. The circular angle going between 0 to 45° corresponds to the hyperbolic angle going from 0 to infinity.
https://en.wikipedia.org/wiki/Hyperbolic_angle
https://en.wikipedia.org/wiki/Hyperbolic_function
[1] Apocryphally, alas.
Don't ruin a good story with facts ;)
 Steve _______________________________________________ Pythonideas mailing list Python...@python.org javascript: https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Pythonideas mailing list Python...@python.org javascript: https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
20180609 8:18 GMT+02:00 Robert Vanden Eynde
:
For the naming convention, scipy using sindg (therefore Nor sind nor sindeg) will make the sind choice less obvious. However if Matlab and Julia chooses sind that's a good path to go, Matlab is pretty popular, as other pointed out, with Universities giving "free" licences and stuff. With that regards, scipy wanting to "be a replacement to Matlab in python and open source" it's interesting they chose sindg and not the Matlab name sind.
I would suggest that compatibility with a major Python library such as SciPy is more important than compatibility with other programming languages. I would go even further and argue that scipy.special.sindg and its friends cosdg and tandg can serve as the reference implementation for this proposal. Stephan
For the "d" as suffix that would mean "d" as "double" like in opengl. Well, let's remember that in Python there's only One floating type, that's a double, and it's called float... So python programmers will not think "sind means it uses a python float and not a python float32 that C99 sinf would". Python programmers would be like "sin takes float in radians, sind takes float in degrees or int, because int can be converted to float when there's no overflow".
Le sam. 9 juin 2018 à 04:09, Wes Turner
a écrit : # Python, NumPy, SymPy, mpmath, sage trigonometric functions https://en.wikipedia.org/wiki/Trigonometric_functions
## Python math module https://docs.python.org/3/library/math.html#trigonometricfunctions  degrees(radians): Float degrees  radians(degrees): Float degrees
## NumPy https://docs.scipy.org/doc/numpy/reference/routines.math.htm l#trigonometricfunctions  degrees(radians) : List[float] degrees  rad2deg(radians): List[float] degrees  radians(degrees) : List[float] radians  deg2rad(degrees): List[float] radians
https://docs.scipy.org/doc/numpy/reference/generated/numpy.sin.html
## SymPy http://docs.sympy.org/latest/modules/functions/elementary.ht ml#sympyfunctionselementarytrigonometric http://docs.sympy.org/latest/modules/functions/elementary.ht ml#trionometricfunctions
 sympy.mpmath.degrees(radians): Float degrees  sympy.mpmath.radians(degrees): Float radians
 https://stackoverflow.com/questions/31072815/cosdandsindwithsympy  cosd, sind  https://stackoverflow.com/questions/31072815/cosdandsind withsympy#comment50176770_31072815
> Let x, theta, phi, etc. be Symbols representing quantities in radians. Keep a list of these symbols: angles = [x, theta, phi]. Then, at the very end, use y.subs([(angle, angle*pi/180) for angle in angles]) to change the meaning of the symbols to degrees"
## mpmath http://mpmath.org/doc/current/functions/trigonometric.html  sympy.mpmath.degrees(radians): Float degrees  sympy.mpmath.radians(degrees): Float radians
## Sage https://doc.sagemath.org/html/en/reference/functions/sage/fu nctions/trig.html
On Friday, June 8, 2018, Robert Vanden Eynde < robertvandeneynde@hotmail.com> wrote:
 Thanks for pointing out a language (Julia) that already had a name convention. Interestingly they don't have a atan2d function. Choosing the same convention as another language is a big plus.
 Adding trig function using floats between 0 and 1 is nice, currently one needs to do sin(tau * t) which is not so bad (from math import tau, tau sounds like turn).
 Julia has sinpi for sin(pi*x), one could have sintau(x) for sin(tau*x) or sinturn(x).
Grads are in the idea of turns but with more problems, as you guys said, grads are used by noone, but turns are more useful. sin(tau * t) For The Win.
 Even though people mentionned 1/6 not being exact, so that advantage over radians isn't that obvious ?
from math import sin, tau from fractions import Fraction sin(Fraction(1,6) * tau) sindeg(Fraction(1,6) * 360)
These already work today by the way.
 As you guys pointed out, using radians implies knowing a little bit about floating point arithmetic and its limitations. Integer are more simple and less error prone. Of course it's useful to know about floats but in many case it's not necessary to learn about it right away, young students just want their player in the game move in a straight line when angle = 90.
 sin(pi/2) == 1 but cos(pi/2) != 0 and sin(3*pi/2) != 1 so sin(pi/2) is kind of an exception.
Le ven. 8 juin 2018 à 09:11, Steven D'Aprano
a écrit : On Fri, Jun 08, 2018 at 03:55:34PM +1000, Chris Angelico wrote:
On Fri, Jun 8, 2018 at 3:45 PM, Steven D'Aprano
wrote: 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.
Having it as a suffix does have one advantage. The math module would need a hyperbolic sine function which accepts an argument in; and then, like Charles Napier [1], Python would finally be able to say "I have sindh".
Ha ha, nice pun, but no, the hyperbolic trig functions never take arguments in degrees. Or radians for that matter. They are "hyperbolic angles", which some electrical engineering text books refer to as "hyperbolic radians", but all the maths text books I've seen don't call them anything other than a real number. (Or sometimes a complex number.)
But for what it's worth, there is a correspondence of a sort between the hyperbolic angle and circular angles. The circular angle going between 0 to 45° corresponds to the hyperbolic angle going from 0 to infinity.
https://en.wikipedia.org/wiki/Hyperbolic_angle
https://en.wikipedia.org/wiki/Hyperbolic_function
[1] Apocryphally, alas.
Don't ruin a good story with facts ;)
 Steve _______________________________________________ Pythonideas mailing list Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Pythonideas mailing list Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Pythonideas mailing list Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
On 6/10/2018 10:44 AM, Stephan Houben wrote:
I would suggest that compatibility with a major Python library such as SciPy is more important than compatibility with other programming languages.
I would go even further and argue that scipy.special.sindg and its friends cosdg and tandg can serve as the reference implementation for this proposal.
Or we could decide that we don't need to duplicate scipy.  Terry Jan Reedy
On Sun, Jun 10, 2018 at 5:41 PM Terry Reedy
On 6/10/2018 10:44 AM, Stephan Houben wrote:
I would suggest that compatibility with a major Python library such as SciPy is more important than compatibility with other programming languages.
I would go even further and argue that scipy.special.sindg and its friends cosdg and tandg can serve as the reference implementation for this proposal.
Or we could decide that we don't need to duplicate scipy.
Copying scipy's and numpy's interface makes vectorizing code a lot simpler. tensorflow also initially made the mistake of varying from numpy's interface only to then deprecate the variations and adopt the standard.
 Terry Jan Reedy
_______________________________________________ Pythonideas mailing list Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/

 You received this message because you are subscribed to a topic in the Google Groups "pythonideas" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/pythonideas/NauPA0ZckE/unsubscribe. To unsubscribe from this group and all its topics, send an email to pythonideas+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
On 6/10/2018 7:53 PM, Neil Girdhar wrote:
On Sun, Jun 10, 2018 at 5:41 PM Terry Reedy
mailto:tjreedy@udel.edu> wrote: On 6/10/2018 10:44 AM, Stephan Houben wrote:
> I would suggest that compatibility with a major Python library such as > SciPy is more important than compatibility > with other programming languages. > > I would go even further and argue that scipy.special.sindg and its > friends cosdg and tandg > can serve as the reference implementation for this proposal.
Or we could decide that we don't need to duplicate scipy.
Copying scipy's and numpy's interface makes vectorizing code a lot simpler. tensorflow also initially made the mistake of varying from numpy's interface only to then deprecate the variations and adopt the standard.
What I meant is to not add functions that already exist in scipy. Core devs do not need the burden of keeping up with whatever improvements are made to the scipy functions.  Terry Jan Reedy
Sym: SymPy, SymEngine, PySym, SymCXX, Diofant
(re: \pi, symbolic computation and trigonometry
instead of surprisingly useful piecewise optimizations)
On Fri, Jun 8, 2018 at 10:09 PM Wes Turner
# Python, NumPy, SymPy, mpmath, sage trigonometric functions https://en.wikipedia.org/wiki/Trigonometric_functions
## Python math module https://docs.python.org/3/library/math.html#trigonometricfunctions  degrees(radians): Float degrees  radians(degrees): Float degrees
## NumPy
https://docs.scipy.org/doc/numpy/reference/routines.math.html#trigonometric...  degrees(radians) : List[float] degrees  rad2deg(radians): List[float] degrees  radians(degrees) : List[float] radians  deg2rad(degrees): List[float] radians
https://docs.scipy.org/doc/numpy/reference/generated/numpy.sin.html
# Symbolic computation
## SymPy
http://docs.sympy.org/latest/modules/functions/elementary.html#sympyfunctio...
http://docs.sympy.org/latest/modules/functions/elementary.html#trionometric...
 sympy.mpmath.degrees(radians): Float degrees  sympy.mpmath.radians(degrees): Float radians
 https://stackoverflow.com/questions/31072815/cosdandsindwithsympy  cosd, sind  https://stackoverflow.com/questions/31072815/cosdandsindwithsympy#commen...
> Let x, theta, phi, etc. be Symbols representing quantities in
radians. Keep a list of these symbols: angles = [x, theta, phi]. Then, at the very end, use y.subs([(angle, angle*pi/180) for angle in angles]) to change the meaning of the symbols to degrees"
http://docs.sympy.org/latest/tutorial/simplification.html#trigonometricsimp... https://github.com/sympy/sympy/blob/master/sympy/functions/elementary/trigon... https://github.com/sympy/sympy/blob/master/sympy/functions/elementary/tests/... https://github.com/sympy/sympy/blob/master/sympy/simplify/trigsimp.py https://github.com/sympy/sympy/blob/master/sympy/simplify/tests/test_trigsim... https://github.com/sympy/sympy/blob/master/sympy/integrals/trigonometry.py https://github.com/sympy/sympy/blob/master/sympy/integrals/tests/test_trigon... https://github.com/sympy/sympy/blob/master/sympy/utilities/tests/test_wester... https://github.com/sympy/sympy/blob/master/sympy/utilities/tests/test_wester... (I. Trigonometry) ## Sym Src: https://github.com/bjodah/sym PyPI: https://pypi.org/project/sym/
sym provides a unified wrapper to some symbolic manipulation libraries in Python. It
## SymEngine  Src: https://github.com/symengine/symengine  Src: https://github.com/symengine/symengine.py  Docs: https://github.com/symengine/symengine/blob/master/doc/design.md  SymEngine / SymPy compatibility tests: https://github.com/symengine/symengine.py/blob/master/symengine/tests/test_s... ## Diofant Src: https://github.com/diofant/diofant https://diofant.readthedocs.io/en/latest/tutorial/intro.html https://diofant.readthedocs.io/en/latest/tutorial/basics.html#substitution https://diofant.readthedocs.io/en/latest/tutorial/simplification.html#trigon... from diofant import symbols, pi x,y,z,_pi = symbols('x y z _pi') expr = pi**x # TODO: see diofant/tests/test_wester.py#L511 expr.subs(x, 1e11) print(operator.sub( expr.subs(pi, 3.14), expr.subs(pi, 3.14159265))) assert expr.subs(pi, 3.14) != expr.subs(pi, 3.14159265) print(expr.subs(pi, 3.14159).evalf(70))  CAS capability tests: https://github.com/diofant/diofant/blob/master/diofant/tests/test_wester.py
""" Tests from Michael Wester's 1999 paper "Review of CAS mathematical capabilities". http://www.math.unm.edu/~wester/cas/book/Wester.pdf See also http://math.unm.edu/~wester/cas_review.html for detailed output of each tested system. """
https://github.com/diofant/diofant/blob/79ae584e949a08/diofant/tests/test_we... # I. Trigonometry
@pytest.mark.xfail def test_I1(): assert tan(7*pi/10) == sqrt(1 + 2/sqrt(5)) @pytest.mark.xfail def test_I2(): assert sqrt((1 + cos(6))/2) == cos(3) def test_I3(): assert cos(n*pi) + sin((4*n  1)*pi/2) == (1)**n  1 def test_I4(): assert cos(pi*cos(n*pi)) + sin(pi/2*cos(n*pi)) == (1)**n  1 @pytest.mark.xfail def test_I5(): assert sin((n**5/5 + n**4/2 + n**3/3  n/30) * pi) == 0
diofant.sin.eval() has a number of interesting conditionals in there: https://github.com/diofant/diofant/blob/master/diofant/functions/elementary/... The tests for diofant.functions.elementary.trigonometric likely have a number of helpful tests for implementing methods dealing with pi and trigonometric identities: https://github.com/diofant/diofant/blob/master/diofant/functions/elementary/... https://github.com/diofant/diofant/blob/master/diofant/simplify/trigsimp.py https://github.com/diofant/diofant/blob/master/diofant/simplify/tests/test_t... https://github.com/diofant/diofant/blob/master/diofant/integrals/tests/test_... https://github.com/diofant/diofant/blob/master/diofant/functions/elementary/... ## mpmath
http://mpmath.org/doc/current/functions/trigonometric.html  sympy.mpmath.degrees(radians): Float degrees  sympy.mpmath.radians(degrees): Float radians
## Sage
https://doc.sagemath.org/html/en/reference/functions/sage/functions/trig.htm...
On Friday, June 8, 2018, Robert Vanden Eynde < robertvandeneynde@hotmail.com> wrote:
 Thanks for pointing out a language (Julia) that already had a name convention. Interestingly they don't have a atan2d function. Choosing the same convention as another language is a big plus.
 Adding trig function using floats between 0 and 1 is nice, currently one needs to do sin(tau * t) which is not so bad (from math import tau, tau sounds like turn).
 Julia has sinpi for sin(pi*x), one could have sintau(x) for sin(tau*x) or sinturn(x).
Grads are in the idea of turns but with more problems, as you guys said, grads are used by noone, but turns are more useful. sin(tau * t) For The Win.
 Even though people mentionned 1/6 not being exact, so that advantage over radians isn't that obvious ?
from math import sin, tau from fractions import Fraction sin(Fraction(1,6) * tau) sindeg(Fraction(1,6) * 360)
These already work today by the way.
 As you guys pointed out, using radians implies knowing a little bit about floating point arithmetic and its limitations. Integer are more simple and less error prone. Of course it's useful to know about floats but in many case it's not necessary to learn about it right away, young students just want their player in the game move in a straight line when angle = 90.
 sin(pi/2) == 1 but cos(pi/2) != 0 and sin(3*pi/2) != 1 so sin(pi/2) is kind of an exception.
Le ven. 8 juin 2018 à 09:11, Steven D'Aprano
a écrit : On Fri, Jun 08, 2018 at 03:55:34PM +1000, Chris Angelico wrote:
On Fri, Jun 8, 2018 at 3:45 PM, Steven D'Aprano
wrote: 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.
Having it as a suffix does have one advantage. The math module would need a hyperbolic sine function which accepts an argument in; and then, like Charles Napier [1], Python would finally be able to say "I have sindh".
Ha ha, nice pun, but no, the hyperbolic trig functions never take arguments in degrees. Or radians for that matter. They are "hyperbolic angles", which some electrical engineering text books refer to as "hyperbolic radians", but all the maths text books I've seen don't call them anything other than a real number. (Or sometimes a complex number.)
But for what it's worth, there is a correspondence of a sort between the hyperbolic angle and circular angles. The circular angle going between 0 to 45° corresponds to the hyperbolic angle going from 0 to infinity.
https://en.wikipedia.org/wiki/Hyperbolic_angle
https://en.wikipedia.org/wiki/Hyperbolic_function
[1] Apocryphally, alas.
Don't ruin a good story with facts ;)
 Steve _______________________________________________ Pythonideas mailing list Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
Maybe a library of trig functions that include an Angle type? This is related to the timespan units discussion we just had def sin(angle): On 20180608 01:44, Yuval Greenfield wrote:
On Thu, Jun 7, 2018 at 10:38 PM Stephen J. Turnbull
mailto:turnbull.stephen.fw@u.tsukuba.ac.jp> wrote: 6.123233995736766e17 >>>
is good enough for government work, including at the local public high school.
There probably is room for a library like "fractions" that represents multiples of pi or degrees precisely. I'm not sure how complicated or valuable of an endeavor that would be. But while I agree that floating point is good enough, we probably can do better.
_______________________________________________ Pythonideas mailing list Pythonideas@python.org https://mail.python.org/mailman/listinfo/pythonideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (16)

Chris Angelico

Greg Ewing

Hugh Fisher

Jacco van Dorp

Kyle Lahnakoski

Neil Girdhar

Richard Damon

Robert Kern

Robert Vanden Eynde

Robert Vanden Eynde

Stephan Houben

Stephen J. Turnbull

Steven D'Aprano

Terry Reedy

Wes Turner

Yuval Greenfield