Home › Forums › General Discussion › Maple Commons general technical discussions

Logical operator Precedence

Posted on 2008-07-16 17:21 By Wolfie7873 (Maple Rating 1 30)
Categories:

OK, this time I'm really stymied.   It appears that Maple doesn't follow the same rules of operator precedence when it comes to logical operators.  p &and q &or r should be the same as r &or p &and q, but it isn't.  What gives, and how can I remedy it?

‹ LPSolve error? grrrr: improper integration, algebraic integrand ›

left associative

Comment on 2008-07-16 20:35 from jakubi (Maple Rating 4 665)

The operators &and, &or have the same precedence and are left associative (?operators,precedence). Then:

with(Logic):
p ∧ q ∨ r;
r ∨ p ∧ q;

                           r ∨ (p ∧ q)
                           q ∧ (r ∨ p)

PS This typesetting effect was unexpected...

I knew that, but why?

Comment on 2008-07-16 21:01 from Wolfie7873 (Maple Rating 1 30)

I interpreted pretty easily for myself what was happening, the question is why?  In the real world, logical operators are not left-associative with equal precedence.  In the real world, and has a greater precedence than or.  Can we force Maple to behave?

 

That real world

Comment on 2008-07-16 21:23 from jakubi (Maple Rating 4 665)

is Mathematics, is an interpretation :)

These are computational representations of mahematical objects. The rules of the computational systems are the creation of one or more developers. So, as I see it, they also convey hints about their minds, the way they think.

So, the answer to why? may be complex. Hopefuly not.

 

Developers vs Founders

Comment on 2008-07-16 22:11 from Alex Smith (Maple Rating 3 248)

I always cringe when we refer to the "Developers" as if they were the "Founders" referenced in Deep Space Nine.

The "Developers" are the ones who decided to orphan Classic Maple, give us that absurd Document Mode, and who believe that they can can do better than Knuth/LaTeX with their "ingenious" 2D input mode.

For math presentation, Knuth is the "Founder."

computer representations aside

Comment on 2008-07-16 22:37 from Wolfie7873 (Maple Rating 1 30)

Maple understands that multiplication trumps addition, so I certainly don't think this was a question of ability.  The question stands, how do I get these interpreted properly?

overloading precedence

Comment on 2008-07-17 17:03 from Wolfie7873 (Maple Rating 1 30)

Anyone know if it's possible to alter the precedence of operators through overloading?

alter the precedence

Comment on 2008-07-18 20:32 from jakubi (Maple Rating 4 665)

If, as it seems, the order of precedence of the operators, as given in ?operators,precedence, is built into the kernel, it cannot be altered. 

alec's picture

Import

Comment on 2008-07-18 20:54 from alec (Maple Rating 4 1443)

It is possible to do using Import function which saves the usual precedence. In the original example,

with(Logic):
  
a:=Import(p and q or r);

                        a := (p &and q) &or r

b:=Import(r or p and q);

                        b := r &or (p &and q)

Equivalent(a,b);

                                 true

Alec

Thank you Alec!

Comment on 2008-07-18 21:09 from Wolfie7873 (Maple Rating 1 30)

Alec to the rescue!  I wonder why this bit of acrobatics is required, though.  seems a bit strange.  But, anyway - thanks so much.  This is the answer I was looking for !

alec's picture

A general tendency

Comment on 2008-07-18 23:44 from alec (Maple Rating 4 1443)

Well, it's hard to tell exactly why. One of possible explanation is that it seems to be a general tendency among CAS creators. Stephen Wolfram developed a new kind of science, and Maplesoft people, probably, didn't want to be left behind - they developed new kinds of Calculus, Algebra, and Logic.

Alec

binding

Comment on 2008-07-19 10:33 from Joe Riel (Maple Rating 4 1115)

The reason that this is not done automatically is that, as mentioned previously in this thread, Maple has no mechanism for changing the binding strength (precedence) of operators.  All neutral operators, with the exception of &*, have the same binding strength.  Converting from active operators works because they have the appropriate precedence so the conversion can use that additional information to properly associate the output.

It would be nice if there were a way to reassign the binding strength of neutral operators.  It seems strange to me that &* has a lower binding strength than other neutral operators; I would have expected the opposite.

 

a little off point?

Comment on 2008-07-19 16:10 from Wolfie7873 (Maple Rating 1 30)

I understand that Maple defined it's &-operators to be neutral and also that they can't be reassigned a different precedence.  All you've done is restate fact without giving reason.  The real question is Why?  It seems such a silly design decision.  The logical operators of the logic package are useless because they have no built-in precedence to mimic the real-world mathematical logic operators that the non-& cousins of theirs have.  (I'm probably just ignorant of some wonderful use for them, but until someone can't point that out, I'm going to have to conclude that Maple got this one wrong.)  Thank goodness that there's at least a way to cope via the Import command.

speculation

Comment on 2008-07-19 16:37 from Joe Riel (Maple Rating 4 1115)

The reason, I suspect, is that reassigning binding strength is not something to be trifled with. How common is it that languages permit reassigning the binding strength of operators?  That seems a rather low-level operation, it affects the parser.  If the binding strengths of neutral operators could be changed arbitrarily, how would mint (the syntax checker) handle it?   One possibility might be to constrain the binding strength of neutral operators to lie within a range, but allow the user to set their relative strength.  The Logic package, when loaded, would then set the relative strengths of its neutral operators accordingly.

I don't see how the missing binding strengths make the logic operators "useless".  Using parentheses allows one to properly associate them; that isn't as nice as otherwise. 

JacquesC's picture

Newer languages can do it

Comment on 2008-07-19 20:52 from JacquesC (Maple Rating 4 1629)

When defining new operators in Haskell, you can also specify its associativity and binding strength.

The problem isn't parsing, that's is actually well-understood.  It is which parsing technology you use.  I don't think the really old stuff (yacc in particular) can do this.  But most modern parsing frameworks have no problems with this.

alec's picture

yacc

Comment on 2008-07-20 13:52 from alec (Maple Rating 4 1443)

Is it flex/bison (or Flex/Bison :) or some other kind of lex/yacc? Java interface seems to be using something different.

Alec

JacquesC's picture

The kernel uses yacc

Comment on 2008-07-20 22:53 from JacquesC (Maple Rating 4 1629)

Last I knew, the kernel used yacc.  I have no clue what the Java interface uses.  I am guessing it's a hand-built parser.

should work like paper

Comment on 2008-07-20 09:28 from Wolfie7873 (Maple Rating 1 30)

I realize that one of my posts was on reassigning things, but that was just as an attempt to get around the real problem and that is that Maple fails to conclude the same thing about a written expression that a reviewer would, should that expression be written on paper. 

My earlier example, p &and q &or r should not require any parentheses to be viewed the same as r &or q &and p, and yet in the Maple Logic package, parens are required for these statements to be equivalent.  That's my problem.  If the answer to a logic question was p /\ q \/ r and a student wrote r \/ q /\ p, they would be counted correct without any parenthesis because of the implied binding strengths of the and and or operators.

We've been arguing in circles, though.  I say Maple should not have defined the &-operators to be neutral with equal binding strength because it makes ambiguous their real-world analogues, and get told that I can't use the &-operators freely because they were defined in a neutral sense and thus can't expect real-world binding strengths. 

I still submit that it makes no sense to me that the logical operators would be defined in a neutral sense with equal binding strength.  That's not how those operators work in logical mathematics, and so should not be the way they work in a mathematical software package.

should work

Comment on 2008-07-20 14:36 from jakubi (Maple Rating 4 665)

as in Mathematics, but sadly these computational representations are not always faithful. May be that technical reasons, ie limitations of the underlying system/language,  among other issues, as discussed before, have a role.

Curiously, the former 'logic' package (available in Maple V) was also implemented using these &-operators. May be that there is no better option?

It would be nice that the author of the 'Logic' package post an explanation.

 

yes, but

Comment on 2008-07-20 16:21 from Joe Riel (Maple Rating 4 1115)

As has been pointed out previously, Maple does not have the ability to reassign precedence of operators.  Given that, there can be no further explanation [package writers generally do not get to touch the kernel].  The author of the Logic package was aware of this limitation.  From the Logic,operators help page:

Precedence
- Note that the Logic package operators do not have the same precedence as
  corresponding three-valued operators. In particular, all operators have the
  same precedence, so a &or b &and c is equivalent to (a &or b) &and c, not a
  &or (b &and c). Parentheses should be used to correctly specify the
  precedence.

The more interesting question is whether we should be able to reassign precedence of otherwise unused neutral operators.  There have been times when I would have found it useful, for example in the ladder notation introduced in the Syrup package as a compact means to describe circuits.  But I see this as a minor convenience. How useful would it be, really?  Jacques mentioned that Haskell provides this ability; has anyone put it to good use?

I mean

Comment on 2008-07-20 17:35 from jakubi (Maple Rating 4 665)

an explanation about the available options for implementation. And the reasons for the current choice, given this limitation on the precedence of the operators. May be that this was the best (or less bad option). It would be better, I think, than speculations about this subject.

Indeed, the question about reasigning precedence is quite interesting. But I wonder how far it is relevant to Maple, in the sense that it could be implemented some day.

JacquesC's picture

Definitely

Comment on 2008-07-20 22:57 from JacquesC (Maple Rating 4 1629)

In Haskell, it is very useful to be able to define the precedence (and associativity) of new operators.  It allows you to define all sorts of nice EDSLs [embedded domain specific languages] in a convenient way.  Rather like 'Logic' is a DSL for logic embedded in mathematics/Maple. 

People have also done some similar things with hygienic macros in Scheme.  I have not looked at the exact details of the technology, but C# 3.0 contains 2 embedded DSLs (one for XML, another for SQL) in a really nice way.

Alternative?

Comment on 2008-07-20 15:03 from jakubi (Maple Rating 4 665)

I do not know whether  this is useful. I have tried with the package  Finding Minimal Sum for Boolean Expression, that uses a different representation:

minbool("pq+r");
Minimal sum: R + PQ
minbool("r+pq");
Minimal sum: R + PQ

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
}