[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Operator precedence tests show 3 failures
From: |
Rik |
Subject: |
Re: Operator precedence tests show 3 failures |
Date: |
Sun, 20 Mar 2011 16:45:07 -0700 |
On 03/20/2011 10:35 AM, John W. Eaton wrote:
> On 20-Mar-2011, Rik wrote:
>
> | On 03/20/2011 01:42 AM, marco atzeri wrote:
> | > On Fri, Mar 18, 2011 at 5:40 PM, Rik wrote:
> | >> 3/18/11
> | >>
> | >> I just checked in some tests for the Octave parser (test_parser.m in
> | >> tests/). The current parser shows 3 failures. These are known, but
> until
> | >> jwe gets a chance to modify his proposed patch be aware that your 'make
> | >> check' will not run cleanly.
> | >>
> | >> --Rik
> | >>
> | >
> | > at least 1 seems obvious
> | > -------------------------------------------
> | > assert ([2, 3] .^ 2',[4; 9]) expected
> | > 4
> | > 9
> | > but got
> | > 4 9
> | > Dimensions don't match
> | > -------------------------------------------
> | >
> | > the test should be:
> | >
> | > assert ([2; 3] .^ 2',[4; 9]) expected
> | >
> | > to match dimensions of argument and result
> | > Marco
> | >
> | Actually, the point is that exponentiation has higher precedence in Octave
> | than the transpose operator. This should be parsed as
> | ([2, 3] .^ 2)'. Instead it is parsed as [2, 3] .^ (2'). Transposing a
> | scalar does nothing nothing so Octave returns a row vector where it should
> | return a column vector. The original bug report is here
> | (https://savannah.gnu.org/bugs/?32533).
> |
> | For Ben's point, we are not trying to match Matlab's equal precedence for
> | transpose and exponentiation.
>
> Are the precedence rules for Matlab documented somewhere?
Yes, here they are if we want to use them. (ref:
http://www.mathworks.com/help/techdoc/matlab_prog/f0-40063.html)
1. Parentheses ()
2. Transpose (.'), power (.^), complex conjugate transpose ('), matrix
power (^)
3. Unary plus (+), unary minus (-), logical negation (~)
4. Multiplication (.*), right division (./), left division (.\), matrix
multiplication (*), matrix right division (/), matrix left division (\)
5. Addition (+), subtraction (-)
6. Colon operator (:)
7. Less than (<), less than or equal to (<=), greater than (>), greater
than or equal to (>=), equal to (==), not equal to (~=)
8. Element-wise AND (&)
9. Element-wise OR (|)
10. Short-circuit AND (&&)
11. Short-circuit OR (||)
>
> | Octave has it's own table for precedence and
> | exponentiation is the highest priority. We merely want to follow our own
> | rules and documented behavior.
>
> With my propopsed patch, the two tests that are failing are
>
> a = 0;
> assert (---a, 1);
>
> and
>
> a = 0;
> assert (!~a++, false)
>
> For the first, I guess we are parsing this as
>
> --(-a)
>
> so the error message about invalid lvalue makes sense. Are you saying
> that this should be parsed as
>
> -(--a)
>
> ? If so, maybe it would be clearer in the tests to write it as
>
> a = 0; b = 0; assert (---a, -(--b))
>
> If this is correct, then I think the problem is with the lexer, which
> is preferring the longest match when generating tokens for the parser,
> so it sees --- as -- -, not - --. I suppose we can fix this with
> additional lookahead.
I put a FIXME line in the tests for this case indicating that we should
really consider whether to bother fixing this outlier. Unless it is simple
to fix, I would propose just accepting the current behavior because there
are clearer ways to write ---a (and any bad programmers who attempt to use
this ungainly construction will be punished by having it fail!)
>
> For the second, it is apparently parsed as
>
> (! (~ a))++
You're right that this is parsing correctly. All three operators !,~,++
are at the same precedence level and so it should be parsed left to right.
On the other hand, the current Octave code does parse this the way you've
written it below. Should the test be changed to make the current code an
error?
> Is that incorrect? Is it supposed to be
>
> ! (~ (a++))
>
> ? I'm not sure what the right fix is for this one.