Priority of unary minus and exponentiation

[Hated Moron]

At another forum a great deal of criticism is being levelled against BBC BASIC for, as they see it, assigning incorrect relative priorities to the unary minus (-) and exponentiation (^) operators in expression evaluation. This is most straightforwardly illustrated in an expression like -5^2:

Code: Select all

      PRINT -5^2

In everyday arithmetic, and in the vast majority of programming languages (including most BASICs), this returns the value -25 because it is evaluated as -(5^2) but in BBC BASIC it returns +25 because it is evaluated as (-5)^2.

Just about the only 'programming language' (apart from BBC BASIC) to return +25 is Microsoft Excel, the spreadsheet application!

Although I was 'there at the time' I have not been able to offer an explanation for this apparently incorrect behaviour; I do not remember any contemporary discussions about it.

Can anybody shed any light on this?

[nvingo]

I wasn't "there" and never involved in compiler/interpreter syntax definition.
A cursory glance at the issue suggests to me (and this is checkable by inspecting the bytes of the program listing - at least it would be on a Sinclair Spectrum which stores both the character and floating-point/integer representation of numbers in a listing) that the "-5" is actually stored as two's complement negative integer before the expression is evaluated.

[Hated Moron]

On 04/11/2022 09:47, J.G.Harston wrote (cross-posted from the Discussion Group):

I think my feeling was that people complaining about the "wrong" result were
confusing uniary minus with subrtraction and thinking -5^2 was shorthand for 0-5^2.

Sorry, no. A list of 'expected' priorities was posted which began something like this (except that it was in Swedish):

Code: Select all

1.  Exponentiation
2.  Unary minus
3.  Multiplication and division
4.  Addition and subtraction
...

So it was recognised that unary minus and subtraction are entirely separate.

You can't argue with the weight of evidence that the vast majority of programming languages do it differently from BBC BASIC (including Microsoft BASIC, which is what we were supposed to be largely compatible with), giving the result -25. Apparently there are also learned papers which state explicitly that exponentiation has a higher priority than unary minus. So whilst BBC BASIC is not unique it is certainly an outlier, and it would be nice to discover why (probably only Sophie could provide the answer now).

[hellomike]

If in BBC BASIC,

Code: Select all

     PRINT -5^2

would amount to -25 instead, then for sure this debate still would have been because people will criticize that! It would even probably be from the very same people!

[Hated Moron]

If in BBC BASIC, PRINT -5^2 would amount to -25 instead, then for sure this debate still would have been because people will criticize that! It would even probably be from the very same people!

This isn't a matter of opinion, it seems pretty clear, on the weight of available evidence, that -25 is correct and +25 is incorrect. Indeed when I tried to defend BBC BASIC at the other forum on the grounds that it was an arbitrary choice, I was presented with extracts from the learned papers I mentioned that it isn't. So I'm perfectly prepared to accept that BBC BASIC (and Excel and perhaps one or two others) are 'wrong', it's not going to make any difference 41 years later!

[Hated Moron]

on a Sinclair Spectrum which stores both the character and floating-point/integer representation of numbers in a listing) that the "-5" is actually stored as two's complement negative integer before the expression is evaluated.

So what does genuine Spectrum BASIC print for -5^2? Paul Dunn, the author of SpecBAS (which is supposed to be highly compatible with the original) said - I think - that his interpreter prints -25.

[nvingo]

An emulated Spectrum on Android (since my real one remains packed away over 20 years) responds with -25
I just meant itt as an example that translates numbers to machine form at program entry rather than execution.

[Hated Moron]

On 04/11/2022 21:08, J.G.Harston wrote (cross-posted from Discussion Group):

In C bitwise operators are higher than comparison. In Python,
comparison operators are higher than bitwise. Which is "correct"?
Both and neither. The only correct answer is: read the documentation.

Yes, quite right: when it comes to bitwise operators and comparison operators there is no agreed standard. But that's not what we are talking about, which is unary minus and exponentiation. In that case there is an acknowledged 'correct' priority, exponentiation is higher than unary minus. It's because BBC BASIC is clearly wrong that I raised it, if it was just an arbitrary choice it would be of little interest.

BBC BASIC has an unusual feature that may have contributed to the anomaly: it's permissible to omit the parentheses from many of the built-in functions. For example it's legitimate to write SINRAD30 rather than SIN(RAD(30)) which would be mandated in most BASICs. This has a particular consequence which is highly relevant: the function's parameter is a numeric factor rather than an expression.

Specifically, the expression evaluator is not called in order to get the parameter value: RAD30+20 does not mean RAD(30+20) it means RAD(30)+20. But we want unary minus to be accepted despite it being a factor, so that SINRAD-30 works; a direct consequence of this is that unary plus and minus become the highest priority operators!

I wonder which came first: did the desire to be able to omit parentheses lead to unary minus incorrectly having a higher priority than exponentiation, or did the incorrect priority come first and a realisation that this allowed the parentheses to be omitted come later. We will probably never know.

[nvingo]

BBC BASIC has an unusual feature that may have contributed to the anomaly: it's permissible to omit the parentheses from many of the built-in functions. For example it's legitimate to write SINRAD30 rather than SIN(RAD(30)) which would be mandated in most BASICs. This has a particular consequence which is highly relevant: the function's parameter is a numeric factor rather than an expression.

Interesting. BBC Basic parsing of the code, matching keywords, ie. stopping at SIN then starting again for RAD; and allowing (though discouraged) capitalised variable names.

Specifically, the expression evaluator is not called in order to get the parameter value: RAD30+20 does not mean RAD(30+20) it means RAD(30)+20. But we want unary minus to be accepted despite it being a factor, so that SINRAD-30 works; a direct consequence of this is that unary plus and minus become the highest priority operators!

Yet is not some kind of 'expression evaluation' invoked to give the result of RAD30 to the operation SIN ?

[Hated Moron]

Yet is not some kind of 'expression evaluation' invoked to give the result of RAD30 to the operation SIN ?

No expression evaluation, no, since there are no operators (and no parentheses); an expression consists of at least two factors combined using at least one operator.

In the source code you can see the distinction between expr() (and exprn(), expri()) which are the entry points for evaluating a numeric expression, and item() (and itemn(), itemi()) which are the entry points for evaluating a numeric factor/item.