[Octave-bug-tracker] [bug #32533] Operator precedence for transpose incorrect

[Rik]

Follow-up Comment #13, bug #32533 (project octave):

>> I also fixed the test for exponentiation. Matlab docs specifically note
that exponentiation is handled left to right. That's odd to me, but I don't
see a compelling reason to do things differently.

Agreed.  It's simpler if is just another left-to-right operator.  This
sentence in expr.txi should be changed to eliminate the reference to
exponentiation: "When operators of equal precedence are used together, the
leftmost operator groups first, except for the assignment and exponentiation
operators, ..." 

>>I also changed the precedence levels of the || and &&, and | and & operators
to match Matlab, with the OR operators having lower precedence than the AND
operators. Should we try to warn about this change in 3.6?

I don't see the logic in having '|' and '&' at different precedence levels and
I don't believe we need to follow Matlab down this path.  But if we do, we
will need some tests in test/test_parser.m to check that the newly inserted
levels are working correctly.  And yes, we will definitely need to post
something to NEWS since a|b&c will now evaluate as a|(b&c) which is the
opposite of the existing (a|b)&c interpretation.  Or more likely, an issue
will result from using the short-circuit operators.  I would expect a || b &&
c to first check condition a.  But now, I'm confused because this can be
re-interpreted as a || (b && c).  Since parentheses have the highest
precedence, does this mean that condition b is checked first?  When using
short-circuit operators I try to have the cheap computational test first, but
I don't know whether that is a or b in this case.  Eventually I'd probably
guess that the parser sees token || token and still evaluates a first, but
that's more thinking and guessing then I like to do :)

>>How should we fix the tests for increment and decrement? The test that
results in an error for an invalid lvalue should be fixed, I think. The
current precedence settings have ++ and -- highest of all except indexing. But
what about ---a? That is an incompatibility with Matlab that will be pretty
much impossible to fix. OTOH, it is probably not something that comes up too
often.

Just scrap the test for ---a.  It's such an obscure corner case and coders
should use parentheses if they have any doubt about how the parser will be
ordering operations.

>>Speaking of the left and right shift operators (<<, >>), should we remove
them? Should we bother deprecating them, or just remove them? There is no
actual use of these operators in any Octave scripting code, but users could
have defined objects that use them. I don't see any in Octave Forge packages
though, so maybe it would be OK to just dump them in 3.6.

What operators are these (<<, >>)?  I just tried

a = 1;
a<<2
error: binary operator `<<' not implemented for `scalar' by `scalar'
operations

in versions 3.0.5, 3.2.4, and 3.4.0.  I think they have already been missing
from Octave for quite awhile so they can probably just be dumped.

>>I'm attaching the new version of the patch. I'd like to get feedback, but
please don't check it in just yet.
No, I'll let you check any patches in.  I would also re-order the operator
precedence chart to be from highest to lowest.  It makes more sense for me to
see item #1 be the most important.  I would also add parentheses '()' as the
first item to make it clear that they trump all other operators.  Finally, the
increment and decrement operators are listed as '+','-','++' whereas I think
it should be only '++','--'.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?32533>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/