[Python-ideas] Trigonometry in degrees

[Robert Vanden Eynde]

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.

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

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

Another option would be to add "deg" or prepend "d" or "deg" however the name 
should be short.

sind, dsin, sindeg or degsin ?

We can look in other languages what they chose.

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.

- Also in the cmath module. Even though the radians make more sense in the 
complex plane. The same functions sin cos tan, asin acos atan, alongside with 
phase and polar.

Here's my current implementation :

def cosd(x):
if x % 90 == 0:
return (1, 0, -1, 0)[int(x // 90) % 4]
else:
return cos(radians(x))

def sind(x):
if x % 90 == 0:
return (0, 1, 0, -1)[int(x // 90) % 4]
else:
return sin(radians(x))

def tand(x):
if x % 90 == 0:
return (0, float('inf'), 0, float('-inf'))[int(x // 90) % 4]
else:
return tan(radians(x))

The infinity being positive of negative is debatable however, here I've chosen 
the convention lim tan(x) as x approaches ±90° from 0

def acosd(x):
if x == 1: return 0
if x == 0: return 90
if x == -1: return 180
return degrees(acos(x))

def asind(x):
if x == 1: return 90
if x == 0: return 0
if x == -1: return -90
return degrees(asin(x))

However, currently [degrees(acos(x)) for x in (1,0,-1)] == [0, 90, 180] on my 
machine so maybe the test isn't necessary.

Testing for Special values of abs(x) == 0.5 could be an idea but I don't think 
the overhead is worth the effort.

Probably this has already been discussed but I don't know how to check that.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Ryan Gonzalez]

You could always do e.g. math.sin(math.degress(radians)) and so forth...


On June 7, 2018 3:07:21 PM Robert Vanden Eynde 
 wrote:


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.


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


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


Another option would be to add "deg" or prepend "d" or "deg" however the 
name should be short.


sind, dsin, sindeg or degsin ?

We can look in other languages what they chose.

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.


- Also in the cmath module. Even though the radians make more sense in the 
complex plane. The same functions sin cos tan, asin acos atan, alongside 
with phase and polar.


Here's my current implementation :

def cosd(x):
if x % 90 == 0:
return (1, 0, -1, 0)[int(x // 90) % 4]
else:
return cos(radians(x))

def sind(x):
if x % 90 == 0:
return (0, 1, 0, -1)[int(x // 90) % 4]
else:
return sin(radians(x))

def tand(x):
if x % 90 == 0:
return (0, float('inf'), 0, float('-inf'))[int(x // 90) % 4]
else:
return tan(radians(x))

The infinity being positive of negative is debatable however, here I've 
chosen the convention lim tan(x) as x approaches ±90° from 0


def acosd(x):
if x == 1: return 0
if x == 0: return 90
if x == -1: return 180
return degrees(acos(x))

def asind(x):
if x == 1: return 90
if x == 0: return 0
if x == -1: return -90
return degrees(asin(x))

However, currently [degrees(acos(x)) for x in (1,0,-1)] == [0, 90, 180] on 
my machine so maybe the test isn't necessary.


Testing for Special values of abs(x) == 0.5 could be an idea but I don't 
think the overhead is worth the effort.


Probably this has already been discussed but I don't know how to check that.


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

Re: [Python-ideas] Trigonometry in degrees

[Rob Speer]

You meant math.radians(degrees), and Robert already mentioned the problem
with this:

>>> math.cos(math.radians(90))
6.123233995736766e-17

On Thu, 7 Jun 2018 at 16:22 Ryan Gonzalez  wrote:

> You could always do e.g. math.sin(math.degress(radians)) and so forth...
>
> On June 7, 2018 3:07:21 PM Robert Vanden Eynde <
> robertvandeney...@hotmail.com> wrote:
>
>> 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.
>>
>> - 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.
>>
>> - 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.
>>
>> Another option would be to add "deg" or prepend "d" or "deg" however the
>> name should be short.
>>
>> sind, dsin, sindeg or degsin ?
>>
>> We can look in other languages what they chose.
>>
>> 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.
>>
>> - Also in the cmath module. Even though the radians make more sense in
>> the complex plane. The same functions sin cos tan, asin acos atan,
>> alongside with phase and polar.
>>
>> Here's my current implementation :
>>
>> def cosd(x):
>> if x % 90 == 0:
>> return (1, 0, -1, 0)[int(x // 90) % 4]
>> else:
>> return cos(radians(x))
>>
>> def sind(x):
>> if x % 90 == 0:
>> return (0, 1, 0, -1)[int(x // 90) % 4]
>> else:
>> return sin(radians(x))
>>
>> def tand(x):
>> if x % 90 == 0:
>> return (0, float('inf'), 0, float('-inf'))[int(x // 90) % 4]
>> else:
>> return tan(radians(x))
>>
>> The infinity being positive of negative is debatable however, here I've
>> chosen the convention lim tan(x) as x approaches ±90° from 0
>>
>> def acosd(x):
>> if x == 1: return 0
>> if x == 0: return 90
>> if x == -1: return 180
>> return degrees(acos(x))
>>
>> def asind(x):
>> if x == 1: return 90
>> if x == 0: return 0
>> if x == -1: return -90
>> return degrees(asin(x))
>>
>> However, currently [degrees(acos(x)) for x in (1,0,-1)] == [0, 90, 180]
>> on my machine so maybe the test isn't necessary.
>>
>> Testing for Special values of abs(x) == 0.5 could be an idea but I don't
>> think the overhead is worth the effort.
>>
>> Probably this has already been discussed but I don't know how to check
>> that.
>> ___
>> 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/

Re: [Python-ideas] Trigonometry in degrees

[Yuval Greenfield]

On Thu, Jun 7, 2018 at 1:07 PM Robert Vanden Eynde <
robertvandeney...@hotmail.com> wrote:

> I suggest adding degrees version of the trigonometric functions in the
> math module.
>
>
You can create a pypi package that suits your needs. If it becomes popular
it could considered for inclusion in the standard library.

Would that work for you?

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

Re: [Python-ideas] Trigonometry in degrees

[Hugh Fisher]

> Date: Thu, 7 Jun 2018 12:33:29 +
> From: Robert Vanden Eynde 
> To: python-ideas 
> Subject: [Python-ideas] Trigonometry in degrees
> Message-ID:
> >
> I suggest adding degrees version of the trigonometric functions in the math 
> module.
>
> - Useful in Teaching and replacing calculators by python, importing something 
> is seen by the young students much more easy than to define a function.

I agree that degrees are useful for teaching. They are also very
useful for graphics
programming, especially with my favourite OpenGL API. But I think that
the use of
radians in programming language APIs is more prevalent, so the initial advantage
of easy learning will be outweighed by the long term inconvenience of
adjusting to
what everyone else is doing.

Writing degrees(x) and radians(x) is a little inconvenient, but it
does make it clear
what units are being used. And even if your proposal is adopted, there
is still going
to be a lot of code around that uses the older math routines. With the
current API
it is a least safe to assume that angles are radians unless stated otherwise.

> - Special values could be treated, aka when the angle is a multiple of 90, 
> young students are often surprise to see that cos(pi/2) != 0
>
> Testing for a special value Isn't very costly (x % 90 == 0) but it could be 
> pointed out that there is a small overhead using the "degrees" equivalent of 
> trig function because of the radians to degrees conversion And the special 
> values testing.

Not just young students :-) I agree with this, but I would prefer the
check to be in
the implementation of the existing functions as well. Any sin/cos very
close to 0
becomes 0, any close to 1 becomes 1.

> - Standard names will be chosen so that everyone will use the same name 
> convention. I suggest adding a "d" like sind, cosd, tand, acosd, asind, 
> atand, atan2d.

Not "d". In the OpenGL 3D API, and many 3D languages/APIs since, appending "d"
means "double precision". It's even sort of implied by the C math
library which has
sinf and friends for single precision.

>
> Creating a new package like 'from math.degrees import cos' however I would 
> not recommend that because "cos" in the source code would mean to lookup the 
> import to know if it's in degrees or radians (and that leads to very filthy 
> bugs). Also "degrees" is already so the name would have to change the name of 
> the package.

Agree, not a good idea.

-- 

cheers,
Hugh Fisher
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Robert Vanden Eynde]

- I didn't know there were sinf in C (that's since C99), I was aware of the
'd' postfix in opengl.

So yeah, sind would be a bad idea, but sindeg or degsin would be too long,
hmm, and I can settle for the Pre or Post fix. sindeg(90) degsin(90) are
both pretty, the first emphasize on the "degree" part and the second on the
"sin(90)" part. I feel I prefer sindeg, cosdeg, atandeg, atan2deg,
phasedeg, rectdeg hmhm

By the way I've seen a stackoverflow answer using Sin and Cos with a
capital letter, doesn't seem very explicit to me.

- I could do a pypi for it for sure, I didn't know it was that easy to
create a repo actually. degreesmath (and degreesmath.cmath ?) would be a
good package name but again I don't want to name the functions sin, cos.
People could rename them on import anyway (let the fools be fools as long
as they don't hurt anyone).

- I agree radians should be the default, but is it especially Because
sin/cos must be in radians ? And because it's more efficient ? The problem
arrises when Mixing units in the same program.

However, should everyone use m³ and not Liters because they're the SI units
? That's more a problems of "mixing units and not sticking to one
convention". I've seen lot of libraries using degrees (and not just good
old glRotate).

Let's notice there are some libraries that wrap units so that one can mix
them safely (and avoid to add meters to seconds).

Let's be honest, radians are useful only when converting arc length, areas
or dealing with derivatives, signals, or complex numbers (engineering
stuffs), and efficiency of sin/cos implementations. When doing simple 2D/3D
applications, angles are just angles and nobody needs to know that
derivative of sin(ax) is a·cos(ax) if x is in radians.

- Integers are more convenient than float, you could add 1 degree every
frame at 60fps to a counter and after 60 frames you'll do a full turn,
adding tau/360 doesn't add so well (floating point representation). Having
exact representation for multiple of 90 degrees is a big plus. Another
advantage is also being able to check if the angle is particular (multiple
of 30 or 90 for example). Especially python Integers with infinite
precision.

- Everyone knows degrees, whereas radians are known only by people that had
math in 10th grade. I know it's easy to say "just convert" but trust me,
not everyone is confident with unit conversions, when you ask "what's the
unit of angle ?" people will think of degrees.

- Changing the behavior for current cos/sin function to have cos(pi/2)
being exact is a bad idea in my opinion, the good old sin/cos from C exist
for a long time and people rely on the behaviors. That would break too much
existing code for no much trouble. And would slow Current applications
relying on the efficiency of the C functions.

- I totally agree writing degrees(...) and radians(...) make it clear and
explicit. That's why I strongly discourage people defining their own "sin"
function that'd take degrees, therefore I look for a new function name
(sindeg).

Le ven. 8 juin 2018 à 00:17, Hugh Fisher  a écrit :

> > Date: Thu, 7 Jun 2018 12:33:29 +
> > From: Robert Vanden Eynde 
> > To: python-ideas 
> > Subject: [Python-ideas] Trigonometry in degrees
> > Message-ID:
> > >
> > I suggest adding degrees version of the trigonometric functions in the
> math module.
> >
> > - Useful in Teaching and replacing calculators by python, importing
> something is seen by the young students much more easy than to define a
> function.
>
> I agree that degrees are useful for teaching. They are also very
> useful for graphics
> programming, especially with my favourite OpenGL API. But I think that
> the use of
> radians in programming language APIs is more prevalent, so the initial
> advantage
> of easy learning will be outweighed by the long term inconvenience of
> adjusting to
> what everyone else is doing.
>
> Writing degrees(x) and radians(x) is a little inconvenient, but it
> does make it clear
> what units are being used. And even if your proposal is adopted, there
> is still going
> to be a lot of code around that uses the older math routines. With the
> current API
> it is a least safe to assume that angles are radians unless stated
> otherwise.
>
> > - Special values could be treated, aka when the angle is a multiple of
> 90, young students are often surprise to see that cos(pi/2) != 0
> >
> > Testing for a special value Isn't very costly (x % 90 == 0) but it could
> be pointed out that there is a small overhead using the "degrees"
> equivalent of trig function because of the radians to degrees conversion
> And the special values testing.
>
> 

Re: [Python-ideas] Trigonometry in degrees

[Richard Damon]

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

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

Re: [Python-ideas] Trigonometry in degrees

[Greg Ewing]

Richard Damon wrote:

First I feel the need to point out that radians are actually fairly
fundamental in trigonometry,


Even more so in calculus, since the derivative of sin(x)
is cos(x) if and only if x is in radians.

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

Re: [Python-ideas] Trigonometry in degrees

[Stephen J. Turnbull]

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: turnb...@sk.tsukuba.ac.jp   University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Yuval Greenfield]

On Thu, Jun 7, 2018 at 10:38 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

>
> 6.123233995736766e-17
> >>>
>
> 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.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Steven D'Aprano]

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.987 (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/#trigonometric-and-hyperbolic-functions

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

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

Re: [Python-ideas] Trigonometry in degrees

[Chris Angelico]

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

ChrisA

[1] Apocryphally, alas.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Steven D'Aprano]

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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Steven D'Aprano]

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.123233995736766e-17
> >>> 
> 
> 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 
old-school 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 
four-function 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 no-brainer, 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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Greg Ewing]

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 + 1000 * pi)
1.0
>>> sin(pi/2 + 1 * pi)
0.9984

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

Re: [Python-ideas] Trigonometry in degrees

[Greg Ewing]

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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Greg Ewing]

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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Jacco van Dorp]

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..
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Steven D'Aprano]

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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Adam Bartoš]

Wouldn't sin(45 * DEG) where DEG = 2 * math.pi / 360 be better that
sind(45)? This way we woudn't have to introduce new functions. (The problem
with nonexact results for nice angles is a separate issue.)

Regards,
Adam Bartoš
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Steven D'Aprano]

On Fri, Jun 08, 2018 at 10:53:34AM +0200, Adam Bartoš wrote:
> Wouldn't sin(45 * DEG) where DEG = 2 * math.pi / 360 be better that
> sind(45)? This way we woudn't have to introduce new functions. (The problem
> with nonexact results for nice angles is a separate issue.)

But that's not a separate issue, that's precisely one of the motives for 
having dedicated trig functions for degrees.

sind(45) (or dsin(45), as I would prefer) could (in principle) return 
the closest possible float to sqrt(2)/2, which sin(45*DEG) does not do:

py> DEG = 2 * math.pi / 360
py> math.sin(45*DEG) == math.sqrt(2)/2
False

Likewise, we'd expect cosd(90) to return zero, not something not-quite 
zero:

py> math.cos(90*DEG)
6.123031769111886e-17



That's how it works in Julia:

julia> sind(45) == sqrt(2)/2
true

julia> cosd(90)
0.0


and I'd expect no less here. If we can't do that, there probably 
wouldn't be much point in the exercise.



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

Re: [Python-ideas] Trigonometry in degrees

[Steven D'Aprano]

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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Hugh Fisher]

> Date: Fri, 8 Jun 2018 15:45:31 +1000
> From: Steven D'Aprano 
> To: python-ideas@python.org
> Subject: Re: [Python-ideas] Trigonometry in degrees
> Message-ID: <20180608054530.gc12...@ando.pearwood.info>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Jun 08, 2018 at 08:17:02AM +1000, Hugh Fisher wrote:
>
>> But I think that the use of
>> radians in programming language APIs is more prevalent, so the initial 
>> advantage
>> of easy learning will be outweighed by the long term inconvenience of
>> adjusting to what everyone else is doing.
>
> But why would you need to?
>
> If we had a degrees API, why wouldn't people just use it?

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

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

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

> I never know what conversion function to use. I always expect something
> like deg2rad and rad2deg. I never remember whether degrees(x) expects an
> angle in degrees or returns an angle in degrees.
>
> So I would disagree that it is clear.

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

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

>> And even if your proposal is adopted, there is still going
>> to be a lot of code around that uses the older math routines.
>
> Why would that be a problem?

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

>> Not just young students :-) I agree with this, but I would prefer the
>> check to be in the implementation of the existing functions as well.
>> Any sin/cos very close to 0 becomes 0, any close to 1 becomes 1.
>
> Heavens no! That's a terrible idea -- that means that functions which
> *ought to return 0.987 (say) will suddenly become horribly
> inaccurate and return 1.
>
> The existing trig functions are as close to accurate as is practical to
> expect with floating point maths. (Although some platform's maths
> libraries are less accurate than others.) We shouldn't make them *less*
> accurate just because some people don't care for more than three decimal
> places.

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

>> Not "d". In the OpenGL 3D API, and many 3D languages/APIs since, appending 
>> "d"
>> means "double precision".
>
> Python floats are already double precision.
>
> What advantage is there for reserving a prefix/suffix because some
> utterly unrelated framework in another language uses it for a completely
> different purpose?

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

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

> Like mathematicians, we use the "h" suffix for hyperbolic sin, cos and
> tan; should we have done something different because C uses ".h" for
> header files, or because the struct module uses "h" as the format code
> for short ints?

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

> Julia provides a full set of trigonometric functions in both radians and
> degrees:
>
&g

Re: [Python-ideas] Trigonometry in degrees

[Kyle Lahnakoski]

On 2018-06-08 01:44, Yuval Greenfield wrote:
> On Thu, Jun 7, 2018 at 10:38 PM Stephen J. Turnbull
>  > wrote:
>
>
> 6.123233995736766e-17
> >>>
>
> 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
unit-specific 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?


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

Re: [Python-ideas] Trigonometry in degrees

[Jacco van Dorp]

2018-06-08 15:19 GMT+02:00 Hugh Fisher :

>> Julia provides a full set of trigonometric functions in both radians and
>> degrees:
>>
>> https://docs.julialang.org/en/release-0.4/manual/mathematical-operations/#trigonometric-and-hyperbolic-functions
>>
>> They use sind, cosd, tand etc for the variants expecting degrees. I
>> think that's much more relevant than OpenGL.
>
> OK, that's interesting, I did not know that. And a quick google shows that
> Matlab also has sind and similar variants for degrees.
>
>> Although personally I prefer the look of d as a prefix:
>>
>> dsin, dcos, dtan
>>
>> That's more obviously pronounced "d(egrees) sin" etc rather than "sined"
>> "tanned" etc.
>
> If Julia and Matlab are sufficiently well known, I would prefer d as suffix
> rather than prefix.

I graduated less than a year ago - Matlab at the very least is quite
well-known, we got lessons about it (although I was the one kid who
used python for his matlab assignments...you can make do, with
matplotlib, google, opencv, and numpy.). I also believe they give
free/heavily discounted licenses to schools, hoping that after
graduation, those students are used to matlab and will try to make
their employers buy full-priced versions.

I don't know about Julia, though.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Adam Bartoš]

Steven D'Aprano wrote:
> On Fri, Jun 08, 2018 at 10:53:34AM +0200, Adam Bartoš wrote:
>> Wouldn't sin(45 * DEG) where DEG = 2 * math.pi / 360 be better that
>> sind(45)? This way we woudn't have to introduce new functions. (The
problem
>> with nonexact results for nice angles is a separate issue.)
>
> But that's not a separate issue, that's precisely one of the motives for
> having dedicated trig functions for degrees.
>
> sind(45) (or dsin(45), as I would prefer) could (in principle) return
> the closest possible float to sqrt(2)/2, which sin(45*DEG) does not do:
>
> py> DEG = 2 * math.pi / 360
> py> math.sin(45*DEG) == math.sqrt(2)/2
> False
>
> Likewise, we'd expect cosd(90) to return zero, not something not-quite
> zero:
>
> py> math.cos(90*DEG)
> 6.123031769111886e-17
>
>
>
> That's how it works in Julia:
>
> julia> sind(45) == sqrt(2)/2
> true
>
> julia> cosd(90)
> 0.0
>
>
> and I'd expect no less here. If we can't do that, there probably
> wouldn't be much point in the exercise.

But if there are both sin and dsin, and you ask about the difference
between them, the obvious answer would be that one takes radians and the
other takes degrees. The point that the degrees version is additionally
exact on special values is an extra benefit. It would be nice to also fix
the original sin, or more precisely to provide a way to give it a
fractional multiple of pi. How about a special class PiMultiple that would
represent a fractional multiple of pi?

PI = PiMultiple(1)
assert PI / 2 == PiMultiple(1, 2)
assert cos(PI / 2) == 0
DEG = 2 * PI / 360
assert sin(45 * DEG) == sqrt(2) / 2

Best regards,
Adam Bartoš
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Richard Damon]

On 6/8/18 5:11 PM, Adam Bartoš wrote:
> Steven D'Aprano wrote:
> > On Fri, Jun 08, 2018 at 10:53:34AM +0200, Adam Bartoš wrote:
> >> Wouldn't sin(45 * DEG) where DEG = 2 * math.pi / 360 be better that
> >> sind(45)? This way we woudn't have to introduce new functions. (The
> problem
> >> with nonexact results for nice angles is a separate issue.)
> >
> > But that's not a separate issue, that's precisely one of the motives
> for
> > having dedicated trig functions for degrees.
> >
> > sind(45) (or dsin(45), as I would prefer) could (in principle) return
> > the closest possible float to sqrt(2)/2, which sin(45*DEG) does not do:
> >
> > py> DEG = 2 * math.pi / 360
> > py> math.sin(45*DEG) == math.sqrt(2)/2
> > False
> >
> > Likewise, we'd expect cosd(90) to return zero, not something not-quite
> > zero:
> >
> > py> math.cos(90*DEG)
> > 6.123031769111886e-17
> >
> >
> >
> > That's how it works in Julia:
> >
> > julia> sind(45) == sqrt(2)/2
> > true
> >
> > julia> cosd(90)
> > 0.0
> >
> >
> > and I'd expect no less here. If we can't do that, there probably
> > wouldn't be much point in the exercise.
>
> But if there are both sin and dsin, and you ask about the difference
> between them, the obvious answer would be that one takes radians and
> the other takes degrees. The point that the degrees version is
> additionally exact on special values is an extra benefit. It would be
> nice to also fix the original sin, or more precisely to provide a way
> to give it a fractional multiple of pi. How about a special class
> PiMultiple that would represent a fractional multiple of pi?
>
> PI = PiMultiple(1)
> assert PI / 2 == PiMultiple(1, 2)
> assert cos(PI / 2) == 0
> DEG = 2 * PI / 360
> assert sin(45 * DEG) == sqrt(2) / 2
>
> Best regards,
> Adam Bartoš
>
In one sense that is why I suggest a Circle based version of the trig
functions. In effect that is a multiple of Tau (= 2*pi) routine.

Richard Damon

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

Re: [Python-ideas] Trigonometry in degrees

[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 
mailto:st...@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 
> mailto:st...@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/

Re: [Python-ideas] Trigonometry in degrees

[Steven D'Aprano]

On Fri, Jun 08, 2018 at 08:45:54AM +, 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 "", line 1, in 
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
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Steven D'Aprano]

On Fri, Jun 08, 2018 at 11:11:09PM +0200, Adam Bartoš wrote:

> But if there are both sin and dsin, and you ask about the difference
> between them, the obvious answer would be that one takes radians and the
> other takes degrees. The point that the degrees version is additionally
> exact on special values is an extra benefit.

No, that's not an extra benefit, it is the only benefit!

If we can't make it exact for the obvious degree angles, there would be 
no point in doing this. We'd just tell people to write their own 
two-line functions:

def sindeg(angle):
return math.sin(math.radians(angle))


The only reason to even consider making this a standard library function 
is if we can do better than that.


> It would be nice to also fix the original sin,

The sin function is not broken and does not need fixing.

(Modulo quirks of individual platform maths libraries.)


> or more precisely to provide a way to give it a
> fractional multiple of pi. How about a special class PiMultiple that would
> represent a fractional multiple of pi?

What is the point of that? When you pass it to math.sin, it still needs 
to be converted to a float before sin can operate on it.

Unless you are proposing a series of dunder methods __sin__ __cos__ and 
__tan__ to allow arbitrary classes to be passed to sin, cos and tan, the 
following cannot work:

> PI = PiMultiple(1)
> assert PI / 2 == PiMultiple(1, 2)
> assert cos(PI / 2) == 0

Without a __cos__ dunder method that allows PiMultiple objects to 
customise the result of cos(), that last line has to fail, because 
cos(math.pi/2) == 0 fails.

> DEG = 2 * PI / 360
> assert sin(45 * DEG) == sqrt(2) / 2

Likewise.




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

Re: [Python-ideas] Trigonometry in degrees

[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#trigonometric-functions
- degrees(radians): Float degrees
- radians(degrees): Float degrees

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



On Friday, June 8, 2018, 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.
>
> - 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
>> ___
>> 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/

Re: [Python-ideas] Trigonometry in degrees

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

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

Re: [Python-ideas] Trigonometry in degrees

[Wes Turner]

On Fri, Jun 8, 2018 at 11:44 PM Robert Kern  wrote:

> 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


## SciPy
https://docs.scipy.org/doc/scipy-1.1.0/reference/special.html#convenience-functions
-
https://docs.scipy.org/doc/scipy-1.1.0/reference/generated/scipy.special.sindg.html#scipy.special.sindg


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

Re: [Python-ideas] Trigonometry in degrees

[Adam Bartoš]

Steven D'Arpano wrote:

> On Fri, Jun 08, 2018 at 11:11:09PM +0200, Adam Bartoš wrote:
>
>>* But if there are both sin and dsin, and you ask about the difference
*>>* between them, the obvious answer would be that one takes radians and the
*>>* other takes degrees. The point that the degrees version is additionally
*>>* exact on special values is an extra benefit.
*>
> No, that's not an extra benefit, it is the only benefit!
>
> If we can't make it exact for the obvious degree angles, there would be
> no point in doing this. We'd just tell people to write their own
> two-line functions:
>
> def sindeg(angle):
> return math.sin(math.radians(angle))
>
>
> The only reason to even consider making this a standard library function
> is if we can do better than that.

I agree completely, I just think it doesn't look obvious.


>>* It would be nice to also fix the original sin,
*>
> The sin function is not broken and does not need fixing.
>
> (Modulo quirks of individual platform maths libraries.)
>
>
>>* or more precisely to provide a way to give it a
*>*> fractional multiple of pi. How about a special class PiMultiple that would
*>*> represent a fractional multiple of pi?
* >
> What is the point of that? When you pass it to math.sin, it still needs
> to be converted to a float before sin can operate on it.
>
> Unless you are proposing a series of dunder methods __sin__ __cos__ and
> __tan__ to allow arbitrary classes to be passed to sin, cos and tan, the
> following cannot work.

The idea was that the functions could handle the PiMultiple instances
in a special way and fall back to float only when a special value is
not detected. It would be like the proposed dsin functionality, but
with a magic class instead of a new set of functions, and without a
particular choice of granularity (360 degrees).
But maybe it isn't worth it. Also what about acos(0)? Should it return
PiMultiple(1, 2) and confuse people or just 1.5707963267948966 and
loose exactness?

Best regards,
Adam Bartoš
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Michael Selik]

On Sat, Jun 9, 2018 at 2:22 AM Adam Bartoš  wrote:

> The idea was that the functions could handle the PiMultiple instances in a 
> special way and fall back to float only when a special value is not detected. 
> It would be like the proposed dsin functionality, but with a magic class 
> instead of a new set of functions, and without a particular choice of 
> granularity (360 degrees).
>
> But maybe it isn't worth it. Also what about acos(0)? Should it return 
> PiMultiple(1, 2) and confuse people or just 1.5707963267948966 and loose 
> exactness?
>
> That'd be the only module in the standard library with such a specialized
class and behavior. You could argue that pathlib creates a sort of Path
preference with str fallback, but the Path type has a large collection of
methods. In contrast, this PiMultiple type would be only used as an input.
That's very unusual style for Python.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Robert Vanden Eynde]

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 
mailto:wes.tur...@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-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.html#sympy-functions-elementary-trigonometric
http://docs.sympy.org/latest/modules/functions/elementary.html#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/functions/trig.html



On Friday, June 8, 2018, Robert Vanden Eynde 
mailto:robertvandeney...@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 
mailto:st...@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 
> mailto:st...@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

Re: [Python-ideas] Trigonometry in degrees

[Neil Girdhar]

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 UTC-4, 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 > 
> 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-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.html#sympy-functions-elementary-trigonometric
>>
>> http://docs.sympy.org/latest/modules/functions/elementary.html#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/functions/trig.html
>>
>>
>>
>> On Friday, June 8, 2018, 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.
>>>
>>> - 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

Re: [Python-ideas] Trigonometry in degrees

[Stephan Houben]

2018-06-09 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#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 <
>> robertvandeney...@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 obviou

Re: [Python-ideas] Trigonometry in degrees

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


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

Re: [Python-ideas] Trigonometry in degrees

[Neil Girdhar]

On Sun, Jun 10, 2018 at 5:41 PM Terry Reedy  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+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Terry Reedy]

On 6/10/2018 7:53 PM, Neil Girdhar wrote:



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


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

Re: [Python-ideas] Trigonometry in degrees

[Wes Turner]

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  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-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
>
>
# Symbolic computation


>
> ## SymPy
>
> http://docs.sympy.org/latest/modules/functions/elementary.html#sympy-functions-elementary-trigonometric
>
> http://docs.sympy.org/latest/modules/functions/elementary.html#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"
>

http://docs.sympy.org/latest/tutorial/simplification.html#trigonometric-simplification

https://github.com/sympy/sympy/blob/master/sympy/functions/elementary/trigonometric.py
https://github.com/sympy/sympy/blob/master/sympy/functions/elementary/tests/test_trigonometric.py#
https://github.com/sympy/sympy/blob/master/sympy/simplify/trigsimp.py
https://github.com/sympy/sympy/blob/master/sympy/simplify/tests/test_trigsimp.py
https://github.com/sympy/sympy/blob/master/sympy/integrals/trigonometry.py
https://github.com/sympy/sympy/blob/master/sympy/integrals/tests/test_trigonometry.py

https://github.com/sympy/sympy/blob/master/sympy/utilities/tests/test_wester.py
https://github.com/sympy/sympy/blob/master/sympy/utilities/tests/test_wester.py#L593
(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_sympy_compat.py

## 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#trigonometric-functions

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_wester.py#L511

# 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/trigonometric.py#L200

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/tests/test_trigonometric.py

https://github.com/diofant/diofant/blob/master/diofant/simplify/trigsimp.py
https://github.com/diofant/diofant/blob/master/diofant/simplify/tests/test_trigsimp.py

Re: [Python-ideas] Trigonometry in degrees

[Kyle Lahnakoski]

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 2018-06-08 01:44, Yuval Greenfield wrote:
> On Thu, Jun 7, 2018 at 10:38 PM Stephen J. Turnbull
>  > wrote:
>
>
> 6.123233995736766e-17
> >>>
>
> 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.
>  
>
>
> ___
> 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/