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.123233995736766e-17

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: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN

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/#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 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

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

Steven D'Aprano wrote:

Even old-school scientific calcuators without the fancy CAS symbolic maths are capable of having cos(90) return zero in degree mode.

FWIW, my Casio fx-100 (over 30 years old) produces exactly 1 for both sin(90°) and sin(pi/2) for its version of pi. -- Greg

Or when students get stuff e-17 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 e-16", 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 performance-critical 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..

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 degree-based 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 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 compile-time. -- Steve

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/scipy-1.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

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 <wes.turner@gmail.com<mailto:wes.turner@gmail.com>> 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#trigonometric-functions - 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#sympy-functio... 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/cosd-and-sind-with-sympy - cosd, sind - https://stackoverflow.com/questions/31072815/cosd-and-sind-with-sympy#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 <robertvandeneynde@hotmail.com<mailto: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 <steve@pearwood.info<mailto:steve@pearwood.info>> 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 <steve@pearwood.info<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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

2018-06-09 8:18 GMT+02:00 Robert Vanden Eynde <robertvandeneynde@hotmail.com

:

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 <wes.turner@gmail.com> 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#trigonometric-functions - degrees(radians): Float degrees - radians(degrees): Float degrees

## NumPy https://docs.scipy.org/doc/numpy/reference/routines.math.htm l#trigonometric-functions - 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#sympy-functions-elementary-trigonometric http://docs.sympy.org/latest/modules/functions/elementary.ht ml#trionometric-functions

- sympy.mpmath.degrees(radians): Float degrees - sympy.mpmath.radians(degrees): Float radians

- https://stackoverflow.com/questions/31072815/cosd-and-sind-with-sympy - cosd, sind - https://stackoverflow.com/questions/31072815/cosd-and-sind -with-sympy#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 <steve@pearwood.info> 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 <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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On Sun, Jun 10, 2018 at 5:41 PM Terry Reedy <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.

-- Terry Jan Reedy

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

--

--- You received this message because you are subscribed to a topic in the Google Groups "python-ideas" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/python-ideas/-NauPA0ZckE/unsubscribe. To unsubscribe from this group and all its topics, send an email to python-ideas+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

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 <wes.turner@gmail.com> wrote:

# 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#trigonometric-functions - 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#sympy-functio...

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/cosd-and-sind-with-sympy - cosd, sind - https://stackoverflow.com/questions/31072815/cosd-and-sind-with-sympy#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#trigonometric-simp... 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 <steve@pearwood.info> 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 <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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/