Re: [Python-ideas] Fwd: Trigonometry in degrees

> Remember, because π is irrational, we cannot actually call sin or cos on > any rational multiple of π. We can only operate on multiples of pi, > which is *close to* but not the same as π. That's why it is okay that > tan(pi/2) returns a huge number instead of infinity or NAN. That's > because the

Re: [Python-ideas] Fwd: Trigonometry in degrees

Op 11 jun. 2018 om 09:18 heeft Jacco van Dorp het volgende geschreven: >> Remember, because π is irrational, we cannot actually call sin or cos on >> any rational multiple of π. We can only operate on multiples of pi, >> which is *close to* but not the same as π. That's why it is okay that >> ta

Re: [Python-ideas] Add hooks to asyncio lifecycle

I like it. First, it solves the issue for policies, and let people decide how they want to deal with the problem (drop the lib, subclass the policy/factory, etc). But it also solves the problem for loops, because loops are set by the task factory, and so you can easily check somebody is changing

Re: [Python-ideas] Fwd: Trigonometry in degrees

2018-06-11 10:00 GMT+02:00 Ronald Oussoren : >> [me suggestion PiMultiple class] > > What is the real world advantage of such a class? So far I’ve only seen > examples where the current behavior is said to be confusing for students. In > most cases where I have used math.sin the angle wasn’t a

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Mon, Jun 11, 2018 at 09:18:22AM +0200, Jacco van Dorp wrote: > > Remember, because π is irrational, we cannot actually call sin or cos on > > any rational multiple of π. We can only operate on multiples of pi, > > which is *close to* but not the same as π. That's why it is okay that > > tan(pi/2

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Mon, Jun 11, 2018 at 12:08:07PM +0200, Jacco van Dorp wrote: > >>> asin(1) > "0.5π" # Currently: 1.5707963267948966 I think that if you expect the stdlib math library to change to symbolic maths for trig functions, you are going to be extremely disappointed. Aside from everything else, this

Re: [Python-ideas] A PEP on introducing variables on 'if' and 'while'

On 11 June 2018 at 04:35, Juancarlo Añez wrote: > > As the PEP author, that's your job. >> > > I started writing the PEP, and I found an interesting example: > > if not (m := re.match(r'^(\d+)-(\d+)$', identifier): > raise ValueError('f{identifier} is not a valid identifier') > pr

Re: [Python-ideas] Add hooks to asyncio lifecycle

> I want to abstract that from the user, so I tried to put that in a policy. But that's dangerous since it can be changed at any time, so I gave up on it and made it explicit. Of course, if the user misses that in the doc (hopefully, it's an company internal code so they should be trained), it will

Re: [Python-ideas] Add hooks to asyncio lifecycle

In my mind aiohttp doesn't depend on On Mon, Jun 11, 2018, 19:24 Yury Selivanov wrote: > > I want to abstract that from the user, so I tried to put that in a > policy. But that's dangerous since it can be changed at any time, so I > gave up on it and made it explicit. Of course, if the user miss

Re: [Python-ideas] Add hooks to asyncio lifecycle

Sorry, smartphone is not my preferred tool. aiohttp doesn't depend on event loop implementation but uses public API only. aiohttp test suite allows to check against asyncio, uvloop, and tokio but it is another story. On Mon, Jun 11, 2018 at 7:35 PM Andrew Svetlov wrote: > In my mind aiohttp does

Re: [Python-ideas] Add hooks to asyncio lifecycle

> aiohttp doesn't depend on event loop implementation but uses public API only. Yeah, I understand. I was using it as an example of what happens if a popular library like aiohttp decides to lock the policy for whatever reason. To add to my point: event loop policies should only be used to inject

Re: [Python-ideas] Add hooks to asyncio lifecycle

Well, if we need something -- locking is better than hooks. But yes, we need a real life example. While the example is absent let's postpone the solution. On Mon, Jun 11, 2018 at 7:50 PM Yury Selivanov wrote: > > aiohttp doesn't depend on event loop implementation but uses public API > only. > >

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Mon, Jun 11, 2018 at 1:00 AM, Ronald Oussoren wrote: > > What is the real world advantage of such a class? So far I’ve only seen > examples where the current behavior is said to be confusing for students. EXACTLY! In [*49*]: math.sin(math.pi) Out[*49*]: 1.2246467991473532e-16 If the diff

Re: [Python-ideas] Fwd: Trigonometry in degrees

Would sind and cosd make Euler's formula work correctly? sind(x) + i * sind(x) == math.e ** (i * x) I suspect that adding these functions is kind of like those cartoons where the boat is springing leaks and the character tried to plug them with their fingers. Floating point is a leaky abstraction

Re: [Python-ideas] Fwd: Trigonometry in degrees

Whoops, it turns out Euler's formula does work! I expected imprecision, but at least one test matched. x = 42 cos(x) + 1j * sin(x) == e ** (1j * x) I suppose that's because it's radians. On Mon, Jun 11, 2018, 10:24 AM Michael Selik wrote: > Would sind and cosd make Euler's formula work correct

Re: [Python-ideas] Fwd: Trigonometry in degrees

2018-06-11 19:33 GMT+02:00 Michael Selik : > Whoops, it turns out Euler's formula does work! I expected imprecision, > but at least one test matched. > > x = 42 > cos(x) + 1j * sin(x) == e ** (1j * x) > I think you will find it holds for any x (except inf, -inf and nan). The boat is less leaky th

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Mon, Jun 11, 2018 at 10:24:42AM -0700, Michael Selik wrote: > Would sind and cosd make Euler's formula work correctly? > > sind(x) + i * sind(x) == math.e ** (i * x) No, using degrees makes Euler's identity *not* work correctly, unless you add in a conversion factor from degrees to radians:

Re: [Python-ideas] Fwd: Trigonometry in degrees

On 2018-06-11 14:04, Stephan Houben wrote: > 2018-06-11 19:33 GMT+02:00 Michael Selik >: > > Whoops, it turns out Euler's formula does work! I expected imprecision, > but at least one test matched. > > x = 42 > cos(x) + 1j * sin(x) == e ** (1j * x) > > > I t

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Mon, Jun 11, 2018 at 10:24 AM, Michael Selik wrote: > Would sind and cosd make Euler's formula work correctly? Not trying to pick on you, but this question shows a key misunderstanding: There is nothing inherently more accurate in using degrees rather than radians for trigonometry. IT's nic

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Mon, Jun 11, 2018, 1:18 PM Chris Barker wrote: > On Mon, Jun 11, 2018 at 10:24 AM, Michael Selik wrote: > >> Would sind and cosd make Euler's formula work correctly? > > > There is nothing inherently more accurate in using degrees rather than > radians for trigonometry. > That's actually wha

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Sun, Jun 10, 2018 at 10:48 PM, Steven D'Aprano wrote: > > > In regard to the "special values", and exact results -- a good math lib > > should return results that are "exact" in all but maybe the last digit > > stored. So you could check inputs and outputs with, e.g. math.isclose() > to > > gi

Re: [Python-ideas] Fwd: Trigonometry in degrees

Michael Selik wrote: Whoops, it turns out Euler's formula does work! I expected imprecision, but at least one test matched. That might be because the implememtation of e ** x where x is complex is using Euler's formula... -- Greg ___ Python-ideas mai

Re: [Python-ideas] Fwd: Trigonometry in degrees

Steven D'Aprano wrote: sin(3°) is: -1/2 (-1)^(29/60) ((-1)^(1/60) - 1) (1 + (-1)^(1/60)) This proposal was supposed to *simplify* the trig functions for non-mathematicians, not make them mind-bogglingly complicated. I don't think anyone is going to complain about sin(3°) not being exact, wha

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Tue, Jun 12, 2018 at 10:57:18AM +1200, Greg Ewing wrote: > Steven D'Aprano wrote: > >sin(3°) is: > > > >-1/2 (-1)^(29/60) ((-1)^(1/60) - 1) (1 + (-1)^(1/60)) > > > >This proposal was supposed to *simplify* the trig functions for > >non-mathematicians, not make them mind-bogglingly complicated.

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Mon, Jun 11, 2018 at 01:18:10PM -0700, Chris Barker via Python-ideas wrote: > On Mon, Jun 11, 2018 at 10:24 AM, Michael Selik wrote: > > > Would sind and cosd make Euler's formula work correctly? > > > Not trying to pick on you, but this question shows a key misunderstanding: > > There is n

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Mon, Jun 11, 2018 at 02:12:06PM -0700, Chris Barker wrote: > no, but you can say "y is as close to zero as I care about" Of course you can. But we (the std lib) should not make that decision for everybody. For some people 0.001 is "close enough to zero". For others, 1e-16 is not. We're not

Re: [Python-ideas] Fwd: Trigonometry in degrees

[Steven D'Aprano] > ... The initial proposal is fine: a separate set of trig functions that take > their arguments in degrees would have no unexpected surprises (only the > expected ones). With a decent implementation i.e. not this one: > > # don't do this > def sind(angle): > ret

Re: [Python-ideas] Fwd: Trigonometry in degrees

Tim Peters wrote: 1. Python's float "%" is unsuitable for argument reduction; e.g., >>> -1e-14 % 360.0 360.0 `math.fmod` is suitable, because it's exact: >>> math.fmod(-1e-14, 360.0) -1e-14 So why doesn't float % use math.fmod? -- Greg ___ Pyth

Re: [Python-ideas] Fwd: Trigonometry in degrees

Sorry for top posting, but these aren't really opinions for the debate, just information. I haven't seen them mentioned, and none grouped nicely under someone's reply. Number representation:: IEEE-754 doubles cannot represent pi correctly at any bit-depth (i mean, obviously, but more seriously).

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Tue, Jun 12, 2018 at 4:40 PM, Greg Ewing wrote: > Tim Peters wrote: > >> 1. Python's float "%" is unsuitable for argument reduction; e.g., >> >> >>> -1e-14 % 360.0 >> 360.0 >> >> `math.fmod` is suitable, because it's exact: >> >> >>> math.fmod(-1e-14, 360.0) >> -1e-14 > > > So why doesn't flo