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.

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.

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 !

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

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?

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?

Yeah, the goto's make me cringe for that very same reason.  Don't know how much is gained by adding my own Maple types, though.  For now, I only have 5 possibilities, so I'll probably stick with goto for now and refactor once I hit 10.

Yeah, the goto's make me cringe for that very same reason.  Don't know how much is gained by adding my own Maple types, though.  For now, I only have 5 possibilities, so I'll probably stick with goto for now and refactor once I hit 10.

Unfortunately, my abstraction layer breaks down pretty quickly if I restrict myself to Maple types instead of made-up ones.  If Goto goes the way of non-rectangular implicitplots, we could be in trouble...

Unfortunately, my abstraction layer breaks down pretty quickly if I restrict myself to Maple types instead of made-up ones.  If Goto goes the way of non-rectangular implicitplots, we could be in trouble...

The tokens that the b's represent are code.  I'm looking for a decision making mechanism.  Basically:

proc(arg1, arg2, calculationType, _rest)

calculationTypes := [type1, type1, type3, etc];

if member(calculationType, calculationTypes, k) then goto(k) else return end if;

1: do this calculation with arg1 and arg2

return;

2: do a different calculation with arg1 and arg2

return;

3: do still something different

return;

Im abstracting a lot of logic out to a single function call, and this proc will handle doling out the proper heavy lifting  based on the type of calculation specified....

The tokens that the b's represent are code.  I'm looking for a decision making mechanism.  Basically:

proc(arg1, arg2, calculationType, _rest)

calculationTypes := [type1, type1, type3, etc];

if member(calculationType, calculationTypes, k) then goto(k) else return end if;

1: do this calculation with arg1 and arg2

return;

2: do a different calculation with arg1 and arg2

return;

3: do still something different

return;

Im abstracting a lot of logic out to a single function call, and this proc will handle doling out the proper heavy lifting  based on the type of calculation specified....

Thanks, Alec,

   I think this will do just what I need. 

Thanks, Alec,

   I think this will do just what I need. 

So how do I get my expected result using command-line or classic Maple 11?