Re: Reason for operator precedence

In article <1142360037.330590.76450@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, matt271829-news@xxxxxxxxxxx writes:

briggs@xxxxxxxxxxxxxxxxx wrote:
In article <1142344511.262841.322440@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, matt271829-news@xxxxxxxxxxx writes:

bri...@xxxxxxxxxxxxxxxxx wrote:
In article <1142342196.542632.294210@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, matt271829-news@xxxxxxxxxxx writes:

Tony wrote:
Hi all.

Hope this isn't a silly question.

I was wondering what the reason is for having multiple levels of operator
precedence?

Phrased another way, why is it that we don't just evaluate everything from
left to right?

Having multiple levels of precedence obviously adds complexity, so I assume
there must be some payback. However, I don't see what it is.


As far as addition/subtraction vs multiplication/division is concerned,
one reason is to ensure that the distributive property of
multiplication works sensibly. For example, we want 3*(4 + 6) = 3*4 +
3*6 = 3*(6 + 4) = 3*6 + 3*4.

Remember that what we're talking about here is merely a notational
convention. It has nothing whatsoever to do with the distributive
property of multiplication over addition.

You can express the distributive law for multiplication over division
using parentheses:

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

Obviously you can. I meant to make it work without needing parentheses,
but it seems that wasn't clear.

Ok. Try doing it using infix notation and the operator precedence
convention of your choice. Remember your rule: no parentheses

Left to right doesn't work.

b+c*a = a*b... and we're stuck

Right to left doesn't work.

b+c*a = ...b*c and we're stuck.

Multiplication has precedence over addition doesn't work.

a*... and we're stuck

Addition has precedence over multiplication doesn't work.

a*b+c = a*b+... and we're stuck

Accordingly, trying to point to this case as a motivation for some
particular choice of operator precedence seems ill conceived.

According to your argument, it follows that we are all using either
Polish (prefix) or Reverse Polish (postfix) notation.

Sorry, you've lost me. I was agreeing with you that even without any
precedence convention we could still represent the distributive law as
a*(b + c) = (a*b) + (a*c). However, the convention makes the
parentheses redundant, because a*b + a*c is understood to mean (a*b) +
(a*c).

Convention makes _SOME OF THE_ parentheses redundant. Your claim is
that _ALL OF THE_ parentheses are redundant.

Please respond to the challenge above. Try to phrase the distributive
law without using parentheses. If you have to resort to prefix or
postfix notation, my case is made. If you can't do it at all, your
case is lost.
.

Relevant Pages

  • Re: Reason for operator precedence
    ... I was wondering what the reason is for having multiple levels of operator ... Having multiple levels of precedence obviously adds complexity, ... I meant to make it work without needing parentheses, ... convention of your choice. ...
    (sci.math)
  • Re: operator precedence in Fortran 2008 draft
    ... to take operands of type BITS. ... to overload the relational operators as well, ... the operator precedence chosen by standard ... forces the use of parentheses in the common cases. ...
    (comp.lang.fortran)
  • Re: Any macro for inserting math "normally"
    ... I don't think that anybody questions the usefulness of infix notation ... and the precedence is often unclear: ... and use parentheses for everything else. ...
    (comp.lang.lisp)
  • Re: question about pointer
    ... parentheses will somehow force complete evaluation of the increment ... Overriding precedence can sometimes have the effect of ... same - the parens are redundant. ...
    (comp.lang.c)
  • Re: Which has higher precedence & or ==
    ... Unfortunately I do have to worry about it. ... George Hester ... >> But I don't know what the precedence was expected here to put the ... > Add parentheses to make it mean what you wanted it to mean - don't worry too ...
    (microsoft.public.vc.language)