Re: Operator precedence problem

2016-06-06 Thread Gregory Ewing
MRAB wrote: In Pascal, "and" has the same precedence as "*" and "or" has the same precedence as "+". Which was annoying, because it gave them higher precedence than the comparison operators, so instead of a = b and c > d you had to write (a = b) and (c > d) -- Greg -- https://mail.py

Re: Operator precedence problem

2016-06-06 Thread Gregory Ewing
Peter Pearson wrote: c b a**(b**c) = a Also, in mathematical texts it's usually written with the c smaller than the b, and the b smaller than the a, which helps to make the precedence clear. We can't do that in Python, unforunately. Unless we allow writing the

Re: Operator precedence problem

2016-06-06 Thread Ben Bacarisse
Rustom Mody writes: > Kernghan/Thomson/Ritchie (dont remember which) actually admitted to the > fact that these precedences are wrong > The mistake that C creators made was to treat bitwise operators as > *logical* rather than as *arithmetic* It was more that they did not take the opportunity t

Re: Operator precedence problem

2016-06-06 Thread MRAB
On 2016-06-06 19:44, Random832 wrote: On Mon, Jun 6, 2016, at 13:07, Steven D'Aprano wrote: Blimey, you're right. I always thought `and` and `or` had the same precedence. And now that I know better, I have no doubt that I will forget it again. A good way to remember it is that "and" is analogo

Re: Operator precedence problem

2016-06-06 Thread Marko Rauhamaa
Random832 : > A good way to remember it is that "and" is analogous to > multiplication, and "or" is analogous to addition. Which is, I assume, > _why_ they have the same precedence. (why ^ is between | and &, > though, is a mystery to me.) APL had a good way of remembering operator precedence: eve

Re: Operator precedence problem

2016-06-06 Thread Random832
On Mon, Jun 6, 2016, at 13:07, Steven D'Aprano wrote: > Blimey, you're right. I always thought `and` and `or` had the same > precedence. And now that I know better, I have no doubt that I will > forget > it again. A good way to remember it is that "and" is analogous to multiplication, and "or" is

Re: Operator precedence problem

2016-06-06 Thread Rustom Mody
On Monday, June 6, 2016 at 7:27:18 PM UTC+5:30, Random832 wrote: > On Mon, Jun 6, 2016, at 01:46, Lawrence D’Oliveiro wrote: > > On Monday, June 6, 2016 at 4:06:20 AM UTC+12, Uri Even-Chen wrote: > > > Never write expressions, such as 2 ** 3 ** 2 or even 2 * 4 > > > + 5, without parentheses. > >

Re: Operator precedence problem

2016-06-06 Thread Steven D'Aprano
On Mon, 6 Jun 2016 11:57 pm, Random832 wrote: > Okay, can we settle on, as a principle, "the basic arithmetic operators > (not to include **) are the only ones whose precedence can be presumed > to be obvious to all readers, Agreed. > and other expressions may/should have > parentheses to mak

Re: Operator precedence problem

2016-06-06 Thread Jon Ribbens
On 2016-06-06, Chris Angelico wrote: > On Tue, Jun 7, 2016 at 2:05 AM, Jon Ribbens > wrote: >> On 2016-06-06, Chris Angelico wrote: >>> In that case, please never insult the intelligence of your future >>> readers by including any of these parentheses: >>> >>> x = 1 + (2 * 3) >> >> I'm not sure w

Re: Operator precedence problem

2016-06-06 Thread Peter Pearson
On Mon, 6 Jun 2016 02:24:37 +1000, Chris Angelico wrote: > On Sun, Jun 5, 2016 at 4:53 PM, ICT Ezy wrote: > 2 ** 3 ** 2 >> Answer is 512 >> Why not 64? >> Order is right-left or left-right? > > This example follows the mathematical standard; you start from the > "top" (the right hand side), a

Re: Operator precedence problem

2016-06-06 Thread Grant Edwards
On 2016-06-06, Chris Angelico wrote: > On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens > wrote: You should put brackets around expressions when it's at all unclear what the meaning is. You could think of them a bit like "active comments" I suppose. >>> >>> Your code should keep noise t

Re: Operator precedence problem

2016-06-06 Thread Peter Otten
Marko Rauhamaa wrote: > Random832 : > >> Sure, it's obvious to _me_ that << and >> have higher precedence than & >> and |, and that "and" has a higher precedence than "or", but can I >> assume the other people know this? > > No need to assume. Just read the spec: > >lambda Lambda ex

Re: Operator precedence problem

2016-06-06 Thread Chris Angelico
On Tue, Jun 7, 2016 at 2:05 AM, Jon Ribbens wrote: > On 2016-06-06, Chris Angelico wrote: >> On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens >> wrote: > You should put brackets around expressions when it's at all unclear > what the meaning is. You could think of them a bit like "active >

Re: Operator precedence problem

2016-06-06 Thread Jon Ribbens
On 2016-06-06, Chris Angelico wrote: > On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens > wrote: You should put brackets around expressions when it's at all unclear what the meaning is. You could think of them a bit like "active comments" I suppose. >>> >>> Your code should keep noise to

Re: Operator precedence problem

2016-06-06 Thread Chris Angelico
On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens wrote: >>> You should put brackets around expressions when it's at all unclear >>> what the meaning is. You could think of them a bit like "active >>> comments" I suppose. >> >> Your code should keep noise to the minimum. > > Sensible and beneficial comm

Re: Operator precedence problem

2016-06-06 Thread Marko Rauhamaa
Jon Ribbens : > On 2016-06-06, Marko Rauhamaa wrote: >> You *can* assume other people have read the spec. Even more >> importantly, you can assume the Python interpreter complies with the >> spec. > > Obviously the latter is true (or at least, it's true except when it's > false). The former howev

Re: Operator precedence problem

2016-06-06 Thread Jon Ribbens
On 2016-06-06, Marko Rauhamaa wrote: > Jon Ribbens : >> On 2016-06-06, Marko Rauhamaa wrote: >>> You *can* assume other people have read the spec. Even more >>> importantly, you can assume the Python interpreter complies with the >>> spec. >> >> Obviously the latter is true (or at least, it's tru

Re: Operator precedence problem

2016-06-06 Thread Marko Rauhamaa
Random832 : > On Mon, Jun 6, 2016, at 10:22, Marko Rauhamaa wrote: >> You *can* assume other people have read the spec. Even more >> importantly, you can assume the Python interpreter complies with the >> spec. > > I can assume the python interpreter will accept tabs as indents too, > that doesn't

Re: Operator precedence problem

2016-06-06 Thread Jon Ribbens
On 2016-06-06, Marko Rauhamaa wrote: > Random832 : >> Sure, it's obvious to _me_ that << and >> have higher precedence than & >> and |, and that "and" has a higher precedence than "or", but can I >> assume the other people know this? > > No need to assume. Just read the spec: The spec tells you t

Re: Operator precedence problem

2016-06-06 Thread Random832
On Mon, Jun 6, 2016, at 10:22, Marko Rauhamaa wrote: > You *can* assume other people have read the spec. Even more importantly, > you can assume the Python interpreter complies with the spec. I can assume the python interpreter will accept tabs as indents too, that doesn't make it good style. Req

Re: Operator precedence problem

2016-06-06 Thread Marko Rauhamaa
Random832 : > Sure, it's obvious to _me_ that << and >> have higher precedence than & > and |, and that "and" has a higher precedence than "or", but can I > assume the other people know this? No need to assume. Just read the spec: lambda Lambda expression if – else Conditional

Re: Operator precedence problem

2016-06-06 Thread Random832
On Mon, Jun 6, 2016, at 01:46, Lawrence D’Oliveiro wrote: > On Monday, June 6, 2016 at 4:06:20 AM UTC+12, Uri Even-Chen wrote: > > Never write expressions, such as 2 ** 3 ** 2 or even 2 * 4 > > + 5, without parentheses. > > That leads to the code equivalent of >

Re: Operator precedence problem

2016-06-06 Thread Gary Herron
On 06/04/2016 11:53 PM, ICT Ezy wrote: 2 ** 3 ** 2 Answer is 512 Why not 64? Order is right-left or left-right? Evidently right to left, but you already figured that out. Python 3.5.1+ (default, Mar 30 2016, 22:46:26) [GCC 5.3.1 20160330] on linux Type "help", "copyright", "credits" or "licen

Re: Operator precedence problem

2016-06-05 Thread Lawrence D’Oliveiro
On Monday, June 6, 2016 at 4:06:20 AM UTC+12, Uri Even-Chen wrote: > Never write expressions, such as 2 ** 3 ** 2 or even 2 * 4 > + 5, without parentheses. That leads to the code equivalent of . -- https

Re: Operator precedence problem

2016-06-05 Thread ICT Ezy
On Sunday, June 5, 2016 at 10:49:49 PM UTC+5:30, Random832 wrote: > On Sun, Jun 5, 2016, at 02:53, ICT Ezy wrote: > > >>> 2 ** 3 ** 2 > > Answer is 512 > > Why not 64? > > Order is right-left or left-right? > > You're mixing up order of evaluation with operator associativity. The ** > operator is

Re: Operator precedence problem

2016-06-05 Thread ICT Ezy
On Monday, June 6, 2016 at 5:18:21 AM UTC+5:30, Michael Torrie wrote: > On 06/05/2016 10:05 AM, Uri Even-Chen wrote: > > My suggestion: Never write expressions, such as 2 ** 3 ** 2 or even 2 * 4 > > + 5, without parentheses. Always add parentheses - 2 ** (3 ** 2) (or (2 ** > > 3) **2) or (2 * 4) +

Re: Operator precedence problem

2016-06-05 Thread ICT Ezy
On Sunday, June 5, 2016 at 9:36:20 PM UTC+5:30, Uri Even-Chen wrote: > My suggestion: Never write expressions, such as 2 ** 3 ** 2 or even 2 * 4 > + 5, without parentheses. Always add parentheses - 2 ** (3 ** 2) (or (2 ** > 3) **2) or (2 * 4) + 5 (or 2 * (4 + 5)). > > > *Uri Even-Chen* > [image:

Re: Operator precedence problem

2016-06-05 Thread Michael Torrie
On 06/05/2016 10:05 AM, Uri Even-Chen wrote: > My suggestion: Never write expressions, such as 2 ** 3 ** 2 or even 2 * 4 > + 5, without parentheses. Always add parentheses - 2 ** (3 ** 2) (or (2 ** > 3) **2) or (2 * 4) + 5 (or 2 * (4 + 5)). I can understand using parenthesis when operator precede

Re: Operator precedence problem

2016-06-05 Thread Random832
On Sun, Jun 5, 2016, at 02:53, ICT Ezy wrote: > >>> 2 ** 3 ** 2 > Answer is 512 > Why not 64? > Order is right-left or left-right? You're mixing up order of evaluation with operator associativity. The ** operator is right-to-left associative, this means x ** y ** z == x ** (y ** z). Evaluation is

Re: Operator precedence problem

2016-06-05 Thread Chris Angelico
On Sun, Jun 5, 2016 at 4:53 PM, ICT Ezy wrote: 2 ** 3 ** 2 > Answer is 512 > Why not 64? > Order is right-left or left-right? This example follows the mathematical standard; you start from the "top" (the right hand side), and work your way down. >>> (3**3) % 10 7 >>> (3**3**3) % 10 7 >>> (3

Re: Operator precedence problem

2016-06-05 Thread Uri Even-Chen
My suggestion: Never write expressions, such as 2 ** 3 ** 2 or even 2 * 4 + 5, without parentheses. Always add parentheses - 2 ** (3 ** 2) (or (2 ** 3) **2) or (2 * 4) + 5 (or 2 * (4 + 5)). *Uri Even-Chen* [image: photo] Phone: +972-54-3995700 Email: u...@speedy.net Website: http://www.speedysof

Re: Operator precedence problem

2016-06-05 Thread ICT Ezy
On Sunday, June 5, 2016 at 1:06:21 PM UTC+5:30, Peter Otten wrote: > ICT Ezy wrote: > > 2 ** 3 ** 2 > > Answer is 512 > > Why not 64? > > Order is right-left or left-right? > > ** is a special case: > > """ > The power operator ** binds less tightly than an arithmetic or bitwise unary > op

Re: Operator precedence problem

2016-06-05 Thread Peter Otten
ICT Ezy wrote: 2 ** 3 ** 2 > Answer is 512 > Why not 64? > Order is right-left or left-right? ** is a special case: """ The power operator ** binds less tightly than an arithmetic or bitwise unary operator on its right, that is, 2**-1 is 0.5. """ https://docs.python.org/3.5/reference/expre

Operator precedence problem

2016-06-04 Thread ICT Ezy
>>> 2 ** 3 ** 2 Answer is 512 Why not 64? Order is right-left or left-right? -- https://mail.python.org/mailman/listinfo/python-list