bugGNU Octave - Bugs: bug #33304, power operator precedence and...


bug #33304: power operator precedence and direction

Submitter:  None
Submitted:  Fri 13 May 2011 09:26:32 AM UTC
Category:  Interpreter Severity:  4 - Important
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  pawel Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.4.0
Operating System:  * Mac OS Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Thu 10 Oct 2013 04:19:25 PM UTC, comment #9: 

I must admit that I'm a bit confused by the comment

The unary operators have to be duplicated because of the context-dependence (lower precedence before the power expression, higher inside).

In any case, I had forgotten about this bug report and recently tried to fix this problem because there is now a test for it in the development version of Octave.  I couldn't come up with anything that would work without breaking something else.  But I wasn't trying to give operators context-dependent precedence either...

I've applied a slightly modified version of Axel's patch here:


so this problem should be fixed in the upcoming 3.8 release.

It seems to fix the problem for me without introducing any new test failures so I'm closing this report.

Thanks, and sorry about the year long delay.

John W. Eaton <jwe>
Group administrator
Thu 06 Sep 2012 07:03:37 AM UTC, comment #8: 

I agree that the duplication of operators is a bit ugly, but I can't see another way to fix this bug.

The unary operators have to be duplicated because of the context-dependence (lower precedence before the power expression, higher inside).

And for the other operators I don't know how to merge them, as replacing them by a new non-terminal causes syntax errors.

Axel Mathéi <amathei>
Tue 04 Sep 2012 07:49:44 PM UTC, comment #7: 

Oops, never mind my last comment about the tests.  I see that you did add some.  I don't know how I missed that.  My apologies.

John W. Eaton <jwe>
Group administrator
Tue 04 Sep 2012 07:48:05 PM UTC, comment #6: 

Thanks for the patch.  It does seem to fix the problem, but I don't like that it duplicates a set of rules for oper_expr in the new power_expr rules.  Do you see a way to avoid that duplication?

Also, we could use some tests for this change.  Probably they belong in test test/test_parser.m script.

John W. Eaton <jwe>
Group administrator
Fri 31 Aug 2012 09:37:19 PM UTC, comment #5: 

Here is a patch fixing this bug.

I first tried to apply the rules suggested in the initial comment, but it brings some problems, especially with the transpose operator that must be at the same precedence level than the power operator.

Instead I introduced a new non-terminal "power_expr", being now the second operand on the "oper_expr" power rules. And in the "power_expr" rules the unary operators have the same precedence level than the power operators, therefore resolving the bug.

(file #26458)

Axel Mathéi <amathei>
Sat 25 Feb 2012 09:30:59 PM UTC, comment #4: 

Raising the status of this issue so that it will be fixed before the 3.8 release.

Rik <rik5>
Group administrator
Sun 15 May 2011 03:23:54 AM UTC, comment #3: 

Verified in Matlab.  Octave should be processing left-to-right and not breaking off when it sees a unary symbol.  This applies to either '+' or '-'.

ans =  1.8447e+19

because this is parsed as 2^(+4^3).

For Matlab, the logical not operator (~) is at the same level of precedence as the unary operators and therefore might need to be processed in the same manner as +/-.

Demonstration code:

2^~0^2 = 2
because Octave parses this as
2^(~0^2) == 2^(~(0^2)) == 2^(~(0)) == 2^(1) == 2
It should probably be parsed as
(2^~0)^2 == (2^1)^2 == (2)^2 = 4

Rik <rik5>
Group administrator
Sun 15 May 2011 01:31:19 AM UTC, comment #2: 

Matlab says:

>> (2^-4)^3

ans =


>> 2^-4^3 

ans =


>> version

ans = (R2009b)

Michael Godfrey <godfrey>
Group Member
Sun 15 May 2011 12:54:24 AM UTC, comment #1: 

This issue is confirmed on the development branch, even with the changes to operator precedence made in changset 002948ae5bc0.

It would be useful if someone with access to Matlab could verify how it handles the situation.  The operator precedence levels are defined here (http://www.mathworks.com/help/techdoc/matlab_prog/f0-40063.html#f0-38155) and they have exponent above unary minus and all operators at the same precedence level acting left-to-right.

Sample code to verify operation:

2^-4^3 = ???

In octave, this is parsed as

2^(-4^3) == 2^(-64) = 5.4210e-20

I agree that I would expect the behavior to be parsed as

(2^-4)^3 == .0625^3 = 2.4414e-04

Rik <rik5>
Group administrator
Fri 13 May 2011 09:26:32 AM UTC, original submission:  


> a^b^c

is evaluated from left to right as

> (a^b)^c

which is eqaul and could or even should be equivalent of

> a^(b*c)

however expression

> -a^-b^-c

is evaluated from right to left

> -a^(-b^-c)

which is not equal

> -a^(-b*(-c))

i think it's serious inconsistency.

The case could be simpler if unary operator had higher priority then power, hovewer i agree that -x^y = -(x^y).

I think that parser should follow semantic like:

unaryExpr:    (+|-|!)? powerExpr;

powerExpr:   atom (^ exp)*;

exp :              (+|-|!)? atom;

atom:             ID | NUMBER | FUNCTION_CALL | ( expression )



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #26458:  power.patch added by amathei (4KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.


    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-10-10 jwe StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2012-08-31 amathei Attached File- Added power.patch, #26458
    2012-02-25 rik5 Severity3 - Normal 4 - Important
    2011-05-15 rik5 StatusNone Confirmed

    Back to the top

    Powered by Savane 3.12