Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #109498 > unrolled thread

Operator precedence problem

Back to article view | Back to comp.lang.python

Contents

  Operator precedence problem ICT Ezy <ictezy@gmail.com> - 2016-06-04 23:53 -0700
    Re: Operator precedence problem Peter Otten <__peter__@web.de> - 2016-06-05 09:35 +0200
      Re: Operator precedence problem ICT Ezy <ictezy@gmail.com> - 2016-06-05 08:05 -0700
        Re: Operator precedence problem Uri Even-Chen <uri@speedy.net> - 2016-06-05 19:05 +0300
          Re: Operator precedence problem ICT Ezy <ictezy@gmail.com> - 2016-06-05 20:24 -0700
          Re: Operator precedence problem Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-05 22:46 -0700
            Re: Operator precedence problem Random832 <random832@fastmail.com> - 2016-06-06 09:57 -0400
              Re: Operator precedence problem Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 17:22 +0300
                Re: Operator precedence problem Random832 <random832@fastmail.com> - 2016-06-06 10:35 -0400
                  Re: Operator precedence problem Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 17:55 +0300
                Re: Operator precedence problem Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-06-06 15:03 +0000
                  Re: Operator precedence problem Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 18:22 +0300
                    Re: Operator precedence problem Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-06-06 15:27 +0000
                      Re: Operator precedence problem Chris Angelico <rosuav@gmail.com> - 2016-06-07 01:57 +1000
                        Re: Operator precedence problem Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-06-06 16:05 +0000
                          Re: Operator precedence problem Chris Angelico <rosuav@gmail.com> - 2016-06-07 02:21 +1000
                            Re: Operator precedence problem Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-06-06 17:02 +0000
                      Re: Operator precedence problem Grant Edwards <grant.b.edwards@gmail.com> - 2016-06-06 16:51 +0000
                Re: Operator precedence problem Peter Otten <__peter__@web.de> - 2016-06-06 18:38 +0200
              Re: Operator precedence problem Steven D'Aprano <steve@pearwood.info> - 2016-06-07 03:07 +1000
                Re: Operator precedence problem Random832 <random832@fastmail.com> - 2016-06-06 14:44 -0400
                  Re: Operator precedence problem Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 21:49 +0300
                Re: Operator precedence problem MRAB <python@mrabarnett.plus.com> - 2016-06-06 20:17 +0100
                  Re: Operator precedence problem Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 11:27 +1200
              Re: Operator precedence problem Rustom Mody <rustompmody@gmail.com> - 2016-06-06 10:14 -0700
                Re: Operator precedence problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-06 21:09 +0100
        Re: Operator precedence problem Michael Torrie <torriem@gmail.com> - 2016-06-05 17:47 -0600
          Re: Operator precedence problem ICT Ezy <ictezy@gmail.com> - 2016-06-05 20:23 -0700
    Re: Operator precedence problem Chris Angelico <rosuav@gmail.com> - 2016-06-06 02:24 +1000
      Re: Operator precedence problem Peter Pearson <pkpearson@nowhere.invalid> - 2016-06-06 16:58 +0000
        Re: Operator precedence problem Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 11:21 +1200
    Re: Operator precedence problem Random832 <random832@fastmail.com> - 2016-06-05 13:19 -0400
      Re: Operator precedence problem ICT Ezy <ictezy@gmail.com> - 2016-06-05 20:23 -0700
    Re: Operator precedence problem Gary Herron <gherron@digipen.edu> - 2016-06-05 00:04 -0700

Page 2 of 2 — ← Prev page 1 [2]

#109587

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 analogous to addition. Which is, I assume, _why_ they have
the same precedence. (why ^ is between | and &, though, is a mystery to
me.)

[toc] | [prev] | [next] | [standalone]

#109588

Random832 <random832@fastmail.com>:
> 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: every operator
was equal and the evaluation order was from right to left.


Marko

[toc] | [prev] | [next] | [standalone]

#109591

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 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.)
>
In Pascal, "and" has the same precedence as "*" and "or" has the same 
precedence as "+".

[toc] | [prev] | [next] | [standalone]

#109598

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

[toc] | [prev] | [next] | [standalone]

#109586

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.
> > 
> > That leads to the code equivalent of
> > <http://i.dailymail.co.uk/i/pix/2011/10/13/article-2048696-03F82C520000044D-302_634x332.jpg>.
> 
> 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, and other expressions may/should have
> parentheses to make it more clear, even when not strictly necessary to
> the meaning of the expression"?
> 
> 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? And I don't know offhand the relative
> precedence of non-conceptually-related groups of operators, except that
> I'm pretty sure "and" and "or" have very low precedence.
> 
> [To keep this on-topic, let's assume that this discussion has a goal of
> getting something along the lines of "always/sometimes/never use
> "unnecessary" parentheses" into PEP7/PEP8. Speaking of, did you know
> that C has lower precedence for the bitwise operators &^| than for
> comparisons? That was something that tripped me up for a very long time
> and undermined my confidence as to other aspects of the bitwise
> operators]

Kernghan/Thomson/Ritchie (dont remember which) actually admitted to the
fact that these precedences are wrong

I believe there are necessary (maybe not sufficient) conditions for a
precedence table
▲ : A × A → B
■ : B × B → C
then ■ should be lower than ▲
because otherwise
(x ■ y) ▲ z comes out type-wrong

Of course these rules are usually more informal than rigorous -- both in
programming and in math
eg in C there is really not much of any type but int
Still if we informally treat 
< : A × A → Bool (A is some kind of numeric)
+,* : A × A → A
&&, || : Bool × Bool → Bool

then it follows that
+,*
< <= etc
&& || 
is the natural precedence table

The mistake that C creators made was to treat bitwise operators as
*logical* rather than as *arithmetic*

[toc] | [prev] | [next] | [standalone]

#109592

Rustom Mody <rustompmody@gmail.com> writes:
<snip>
> Kernghan/Thomson/Ritchie (dont remember which) actually admitted to the
> fact that these precedences are wrong
<snip>
> 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 to change them.  C
grew out of B, and B had only the one form of & and |.  These were
bitwise operators but, since they they were more often used for logical
combinations of tests, it made sense to give them low precedence.

When && and || were added to C, & and | should probably have been
"bumped up", but when you have a bunch of people who already know B (and
a bunch of B code you might be converting to C) it's easy to see why you
might not make that change.  After all, it's not like the language is
going to used for much more than this experimental Unix thingy!

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#109528

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 precedence isn't
working the way you want or expect, but I certainly would not recommend
using it for basic arithmetic with multiplication, division, addition
and subtraction. The rules of precedence for multiplication and division
are well known and well-understood. If a language failed to implement
them that would be a bug.  I think for the simple things extraneous
parenthesis makes expressions more difficult for a human to parse
because he will tend to second guess himself owing to extra parens.

[toc] | [prev] | [next] | [standalone]

#109533

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) + 5 (or 2 * (4 + 5)).
> 
> I can understand using parenthesis when operator precedence isn't
> working the way you want or expect, but I certainly would not recommend
> using it for basic arithmetic with multiplication, division, addition
> and subtraction. The rules of precedence for multiplication and division
> are well known and well-understood. If a language failed to implement
> them that would be a bug.  I think for the simple things extraneous
> parenthesis makes expressions more difficult for a human to parse
> because he will tend to second guess himself owing to extra parens.

Thank you very much for your explanation

[toc] | [prev] | [next] | [standalone]

#109517

On Sun, Jun 5, 2016 at 4:53 PM, ICT Ezy <ictezy@gmail.com> 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**3**3**3) % 10
.... waiting......

https://en.wikipedia.org/wiki/Graham%27s_number

ChrisA

[toc] | [prev] | [next] | [standalone]

#109583

On Mon, 6 Jun 2016 02:24:37 +1000, Chris Angelico <rosuav@gmail.com> wrote:
> On Sun, Jun 5, 2016 at 4:53 PM, ICT Ezy <ictezy@gmail.com> 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.
[snip]

This is almost certainly why top-down was the desirable choice.  And
as for why mathematicians chose top-down (probably long before any
programming-language designer faced the decision), note that this
convention allows you to write both (a**b)**c and a**(b**c) without
parentheses, making expressions cleaner than otherwise:

               bc
  (a**b)**c = a

                c
               b
  a**(b**c) = a

-- 
To email me, substitute nowhere->runbox, invalid->com.

[toc] | [prev] | [next] | [standalone]

#109597

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 source in html...

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#109519

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 left to right, where it matters [i.e. if one or
more of the elements here were an expression with side effects]: first x
is evaluated, then tmp=y**z, then x**tmp. These are two entirely
different concepts.

[toc] | [prev] | [next] | [standalone]

#109534

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 right-to-left associative, this means x ** y ** z == x ** (y
> ** z). Evaluation is left to right, where it matters [i.e. if one or
> more of the elements here were an expression with side effects]: first x
> is evaluated, then tmp=y**z, then x**tmp. These are two entirely
> different concepts.

Thank you very much for your explanation

[toc] | [prev] | [next] | [standalone]

#109555

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 "license" for more information.
 >>> 2 ** 3 ** 2
512
 >>> 2 ** (3 ** 2)
512
 >>> (2 ** 3) ** 2
64
 >>>


Here's the relevant documentation page:
     https://docs.python.org/3/reference/expressions.html
Look for "... except for exponentiation, which groups from right to left"

Gary Herron

-- 
Dr. Gary Herron
Professor of Computer Science
DigiPen Institute of Technology
(425) 895-4418

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web