Power operator (^) precedence levels and evaluation order

Question

creepydog 2024-6-21

2
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/2130776-power-operator-precedence-levels-and-evaluation-order

评论： dpb 2024-7-21

采纳的回答： Oliver Jaehrig

在 MATLAB Online 中打开

While

2^-1^-2

returns 4, which indicates a "left to right" evaluation order (as it is common in many programming languages),

2^-1^-2^3

returns 0.125, which I find surprising – I would have expected a value of 4^3 = 64.

To examine the order applied by Matlab, I tried all possible combinations:

((2^-1)^-2)^3      % returns 64     (1st, then 2nd operator)
(2^-1)^-(2^3)      % returns 256    (1st and 3rd)
(2^-(1^-2))^3      % returns 0.125  (2nd, then 1st)
2^-((1^-2)^3)      % returns 0.5    (2nd, then 3rd)
2^-(1^-(2^3))      % returns 0.5    (3rd, then 2nd)

So it seems that Matlab first evaluates the 2nd operator, then the 1st (=left), then the 3rd (=rightmost). That seems very odd. Can anybody explain why Matlab chooses this evaluation order?

I'm aware of https://de.mathworks.com/help/matlab/matlab_prog/operator-precedence.html, but it just doesn't make sense to me. According to the rules given there, the 3rd operator (^) in my example should even come first, as it has a higher precedence than the other two (^-) operators. So doesn't Matlab adhere to its own rules?

18 个评论
显示 16更早的评论隐藏 16更早的评论

dpb 2024-6-21

This (and the other thread) poiint out a problem with proprietary languages such as MATLAB -- it is not required there be a published language specification that unambiguously defines all corners of the language and has an accessible standards group to which one can submit such arcane cases to for resolution -- either explain the rule or cause a correction to be generated in the rare case that an actual problem is uncovered.

MATLAB, otoh, while there undoubtedly is somewhere within TMW (The Mathworks) something that purports to be/serves as such a standard, it is not available outside Natick and all the language definition provided is in the documentation which is, for the most part, example-based rather than be definitive rules.

Hence, there is no way to answer the question raised here with what is publicly available, TMW simply doesn't publish those considered proprietary details for competitive reasons.

One could submit a bug report and see what the response is, but "WAD" (Working as Designed) is probably about all that will be allowed to. Although it could be interesting to see how they might explain the way in which the calculation and the apparent application of the precedence rules differ -- or how the interpretation of the documentation on the rules can be interpreted to come up with the result.

Paul 2024-6-22

@dpb

If the documentation is not complete or is an error, then, ideally, the documentation needs to be fixed. If there is a bug in the Matlab implementation, then, ideally, that bug should be fixed. I think we agree on this.

For me, all this thread proves is that we have one of those two situations. FWIW, which is probably not much, when I need to deal with other programing languages (e.g., FORTRAN, C++) and need to understand how some code works, I just go to the vendor-provided user's guide, manual, or whatever they call it. I don't think I've ever gone to look up anything in a formal standard. Of course, YMMV.

Based on the historical discussion of this issue, I too have a conjecture as to why Matlab does this (peculiar?) start-from-second-from-the-right thing for bunch of operators, but it's just conjecture.

What I am mildly curious about is whether any other language defines operators analogous to Matlab's ^+ and ^- (and the others at the same precedence as those). I've never seen such, but I'm not knowledgeable about many languages. For example, in FORTRAN

3**-2

is an expression with two operators: exponentiation(**) and unary minus (-), whereas in Matab that expression would use a single operator (^-) .

@creepydog

If you are going to (or already have) opened a support request on this issue, if you don't mind please comment back on this thread with a summary MathWorks's adjudication.

dpb 2024-6-22

编辑：dpb 2024-6-24

If the documentation is not complete or is an error, then, ideally, the documentation needs to be fixed. If there is a bug in the Matlab implementation, then, ideally, that bug should be fixed. I think we agree on this."

If it is the former, I agree; I have submitted bug/enhancement reports for several corrections/additions to the documentation over the years; most if not all of those have been incorporated.

In this case, if there is actually a discrepancy between what the formal language specification requires(*) and the implementation (and not, as I suspect, simply that the user documentation is not complete in covering all possible combinations of operators and order of each), I would expect it will be the implementation that wins and the specification modified to match--there's simply too much precedence and historical code (including MATLAB/Mathworks code itself) to go munging on this.

(*) I continue in my belief there simply has to be such internally

"If you are going to (or already have) opened a support request on this issue, ..."

I think it is a case where a support request should indeed be submitted asking for clarification of the rules and that the documentation be amplified to be complete and unambiguous. I do not disagree with the general precept that lacking the formal design document to refer to, the user documentation should serve in its stead. The problem TMW has is that they chose to make the documentation example and narrative based(+) in order to try to be "user friendly" and consequently normative text gets the short end of the stick when things get sticky as here.

(+) It's annoying the Examples section comes before the normative definition of arguments although sometimes it's only by a combination of studying both one can finally understand some of the more complex syntax.

dpb 2024-6-24

It will be most interesting to hear the result...

creepydog 2024-6-28

TMW has answered my support request (see accepted answer), which referred to this thread but contained its own example and focus. The answer isn't 42, but the corresponding question shouldn't be unknown anyway. So, for completeness and transparency, I'd like to post the full text of my support request here:

<quote>

If you run this expression in the Command Window:

>> 2^+3^2

Matlab returns ans = 64, which shows that it was evaluated from left to right, i.e. as (2^+3)^2. Otherwise the result would be 512.

The operator precedence documentation [1] says that there are two different precedence levels for power operators (levels 2 and 3). The normal matrix power operator ^ has precedence level 2, while the "matrix power with unary plus" operator ^+ has level 3, which is inferior to level 2. So, according to the documentation, 2^+3^2 should be evaluated as 2^+(3^2), because the ^ operator has higher precedence than ^+ (like 2+3*4 is 14, not 20).

There's a note in the documentation [1] saying that level 3 operators deviate from the normal left-to-right rule [2], but that only matters within (!) this precedence level 3. Operators of precedence level <= 2 still have priority over operators of level 3, so ^ must precede ^+ according to the documentation, regardless of left/right aspects.

Please also see my question and the discussion with/of several MVPs in Matlab Central [3] for more examples and thoughts about this problem.

[1] https://de.mathworks.com/help/matlab/matlab_prog/operator-precedence.html

[2] They "work from second from the right to left", I'm not sure what that means, linguistically.

[3] https://de.mathworks.com/matlabcentral/answers/2130776-power-operator-precedence-levels-and-evaluation-order

</quote>

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Oliver Jaehrig 2024-6-28

3
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/2130776-power-operator-precedence-levels-and-evaluation-order#answer_1478281

在 MATLAB Online 中打开

The statement below is coming from our development team and they reviewed the discussion on MATLAB Answers and the incoming support request regarding it:

We agree that the current behavior is unusual. Unfortunately, it's decades-old MATLAB behavior. We may choose to change it, but it cannot change suddenly without adequate notice.

We strongly recommend using parentheses to clarify the intended order of operations. The Code Analyzer suggests this, and early versions of MATLAB actually required this.

To clarify what is meant by "second from the right to left" in the doc,

a^-b^-c^-d^-e^-f

is parsed as

(a ^ (- (b ^ (- (c ^ (- (d ^ (- e)))))))) ^ (- f)

which is essentially equivalent to

X1 = -(d^-e);
X2 = -(c^X1);
X3 = -(b^X2);
X4 = a^X3;
X5 = X4^-f

Our development team considers to enhance the documentation about this in a future release. If there are any further questions, please let me know, or create a new support request if needed.

18 个评论
显示 16更早的评论隐藏 16更早的评论

creepydog 2024-6-28

编辑：creepydog 2024-6-28

Thanks for the hint. No, I didn't. The examples discussed here so far certainly don't cover all cases/combinations of mixed levels. TMW's answer made it clear what "second from the right to left" means (that might have been clear to others but it hasn't been to me) and that the documentation does not completely correctly describe Matlab's behavior at the moment because that order rule should only be applied for pure level 3 statements (i.e. after evaluating all level 2 operators) which it isn't. This can be seen from my second example "2^-1^-2^3".

My experiments suggest that this violation only occurs for the rightmost operator (but remember: proof by example is dangerous). One last example for this: While a^b^c^d^e^f is evaluated left-to-right, mixing in one level 3 operator at the beginning (a^+b^c^d^e^f) changes it to (a^(((b^c)^d)^e))^f. Note that it's still left-to-right from b to e, and that a^+ comes only after that, but the ^f is applied last despite being level 2.

Edit/Addendum: I now used the Symbolic Toolbox for my last example. I hope that doesn't introduce additional differences.

Paul 2024-6-29

Hi dpb,

"The "-" in the example expression isn't part of a unary operator "^-" but the minus sign applied to the exponent. "

If "^-" is an operator at all, it wouldn't be a unary operator. It would be a binary operator.

But, as we've both pointed out, it looks like the "-" in "^-" is being treated as a unary operator uminus, - on the exponent, which is then followed by applying the binary operator "^" mpower, ^. In other words, "^-" appears to not be an operator and of itself.

However, the Operator Precedence page that started this whole discussion states:

" ... the operators (^-), (.^-), (^+), (.^+), ..."

which can't be ready any other way than that all four of those are each single (not unary) operators.

However, none of (^-), (.^-), (^+), (.^+) are actually listed as arithmetic operators at Matlab Operators and Special Characters, which strongly suggests that that those four (and the others with power and negation that we haven't been talking about) are actually treated as two, separate operations, as we both suspect. But if that's the case, I can't fathom why the Operator Precedence page is written the way it is.

dpb 2024-6-29

编辑：dpb 2024-6-29

在 MATLAB Online 中打开

For (^-) to be interpreted as a unary operator for exponentiation with a negative exponent the original expression would had to have been written as

2^--2
ans = 4

to be equivalent to

(1/2)^-2
ans = 4

so that part seems ok to me; the part that may be omitted in describing the parsing with negative exponents is that the sign character (if present) of the exponent is applied first because it's part of parsing a constant before it gets to the exponentiation part of the interpretation of the whole string. (Then again, maybe that doesn't belong since it's part of interpreting a number from a text stream not the exponent. :J)

2^-2
2^-(2)
2^-+2

all equate to 1/4, in the latter the (superfluous) "+" is handled correctly as well.

I've not played with the more complex expressions enough to decide about the ordering rule, although it does seem as though @creepydog's example breaks with the two precedence levels.

You can't try to make the operator stand on its own though...

2(^-)-2
Invalid expression. When calling a function or indexing a variable, use parentheses. Otherwise, check for mismatched delimiters.

dpb 2024-6-30

编辑：dpb 2024-6-30

My bad using "unary" in two meanings--I just meant the interpretation of the two-character sequence as a single atomic operator; which I thought your previous response indicated you thought that rule was being broken.

My illustration is simply that the prior example was not actually the "^-" operator syntax with a negative exponent because it (the example) lacks the second negative sign to actually make the operator, the single negative sign is used to create a negative exponent value, but then the operator is simply "^", not "^-".

The last that illustrated that one cannot, in fact, segregate the operator sequence was done simply for the purpose of showing that if one hadn't tried; nothing else. I thought it possible from the stylistic form somebody might think it at least possible (and, actually, was curious myself as to what the parser would do with the superfluous set).

In short, in retrospect I wonder if @creepydog may need to rethink his expectation of the examples.

dpb 2024-7-1

编辑：dpb 2024-7-1

@creepydog Indeed! :)

I think the Q? you raise is the point -- that the "-" gets interpreted first and eaten as the unary negation operator by the interpretation of the complete exponent expression before the parsing of the rest of the expression. Hence, the two "-" in succession example. That is, what isn't included in the explicit rules/description is that the unary negation is higher precedence and so it also doesn't necessarily parse from left to right and so just because a "-" follows a "^" doesn't necessarily produce the "^-" operator.

For the single case, I think the examples show that to be so; the chaining and more complex cases are still in doubt as to the rules, agreed.

I'm certainly glad to not be a compiler developer; I'd hate to have to try to implement these kinds of rules. :J

I think the supposition that all TMW will change may be the documentation to (at least try) to clarify what the actual implementation is will be the only action taken if a more specific support question is not raised.

In real life, the Answer of "use parentheses to ensure you get what you want" appears to be the only way to proceed and that to write compound expression without explicit grouping to clarify intent is risky and one better test the result if write such.

Julian Hapke 2024-7-21

编辑：dpb 2024-7-21

在 MATLAB Online 中打开

You can see how MATLAB evaluates an expression by using the mtree function. It does indeed not recognize ^+ as it's own operator, but as soon as there is a unary operator inside an exponent, it influences the abstract syntax tree of the whole expression, e.g.:

```

dump(mtree('5 ^ 4 ^ 3 ^ 2'))
1===  *  PRINT:   1/11 
2===     *  EXP:   1/11 
3===        *  EXP:   1/07 
4===           *  EXP:   1/03 
5===              *  INT:   1/01  (5)
6===              *  INT:   1/05  (4)
7===           *  INT:   1/09  (3)
8===        *  INT:   1/13  (2)
dump(mtree('5 ^+ 4 ^ 3 ^ 2'))
1===  *  PRINT:   1/12 
2===     *  EXP:   1/12 
3===        *  EXP:   1/03 
4===           *  INT:   1/01  (5)
5===           *  UPLUS:   1/04 
6===              *  EXP:   1/08 
7===                 *  INT:   1/06  (4)
8===                 *  INT:   1/10  (3)
9===        *  INT:   1/14  (2)
```
5 ^ 4 ^ 3 ^ 2 == (((5 ^ 4) ^ 3) ^ 2)
and 
5 ^+ 4 ^ 3 ^ 2 == (5 ^+ (4 ^ 3)) ^ 2

dpb 2024-7-21

Interesting, thanks! I was not aware of mtree after 30 years...

请先登录，再进行评论。

Power operator (^) precedence levels and evaluation order

18 个评论
显示 16更早的评论隐藏 16更早的评论

采纳的回答

18 个评论
显示 16更早的评论隐藏 16更早的评论

更多回答（0 个）

另请参阅

类别

标签

产品

版本

Community Treasure Hunt

Power operator (^) precedence levels and evaluation order

18 个评论 显示 16更早的评论隐藏 16更早的评论

采纳的回答

18 个评论 显示 16更早的评论隐藏 16更早的评论

更多回答（0 个）

另请参阅

类别

标签

产品

版本

Community Treasure Hunt

18 个评论
显示 16更早的评论隐藏 16更早的评论

18 个评论
显示 16更早的评论隐藏 16更早的评论