Unary minus precedence preference

[Claudio L.]

(07-23-2014 10:10 PM)htom trites Wrote:  This really comes down to precedence and associations. Part of the reason that 0-2^2 "feels like" -4 is that our minds bind the - as a subtraction (which it is, it's not unary!)

The conflict is that unary - , to be truly unary, has to bind as or higher than parentheses; -2^2 has to become (-2)^2.

So there is no unary -, it's just a writing convention of deleting the 0.

Regarding the existence or not of the unary minus operator, I think in computing the unary minus is very real. I don't know if it meets your standards to be "truly unary" but it is real enough for all HP calculators to have a key dedicated to the unary minus (NEG, +/-, CHS), and a separate one for the binary minus.
And more so thinking in RPN, where there's no ambiguity, no operator precedence, and not even algebraic expressions. Yet the unary minus exists by itself.
I could also point out that in two's complement, the unary minus is not defined as (0-x), but it's defined as (~x)+1, where ~ is an operator that toggles all bits (XOR 0xFFFFFFF...). Granted, with the properly defined subtraction in the same domain, 0-x should give the same result as -x, but the definition of the unary minus exists by itself and is independent from the binary minus. And in hardware where you have only adders, it's common to define the binary minus in terms of the unary minus:
a-b = a+(-b) = a+(~b)+1
So in that case, the unary minus exists, but the binary minus doesn't!
And I guess you could generalize that and say that the subtraction doesn't exist, it's actually the addition of a negative number.
It's all a matter of perspective.

Claudio

[Wes Loewer]

(07-23-2014 08:27 PM)Wes Loewer Wrote:  Well, except for that pesky Excel again. It evaluates 2^3^2 to be 64 instead of 512.

In fact, the only spreadsheets that I've found so far that give 512 are Google Sheets and Gnumeric on Linux. Gnumeric is even kind enough to automatically insert parentheses to explicitly show 2^(3^2) as well as (-2)^2.

So, a few spreadsheets do -2^2 correctly and a few do 2^3^2 correctly, but I'm not aware of any spreadsheets that do both of these operations correctly.

[Marcus von Cube]

(07-24-2014 07:31 AM)Wes Loewer Wrote:  So, a few spreadsheets do -2^2 correctly and a few do 2^3^2 correctly, but I'm not aware of any spreadsheets that do both of these operations correctly.

I suppose this has to do with the intended audience of a spreadsheet application: It's the same group of people who set their business calculators to chain mode. Don't expect anything more complicated from them.

[walter b]

(07-24-2014 08:53 AM)Marcus von Cube Wrote:  

(07-24-2014 07:31 AM)Wes Loewer Wrote:  So, a few spreadsheets do -2^2 correctly and a few do 2^3^2 correctly, but I'm not aware of any spreadsheets that do both of these operations correctly.

I suppose this has to do with the intended audience of a spreadsheet application: It's the same group of people who set their business calculators to chain mode. Don't expect anything more complicated from them.

As mentioned above already.

d:-)

[Claudio L.]

(07-24-2014 07:31 AM)Wes Loewer Wrote:  

(07-23-2014 08:27 PM)Wes Loewer Wrote:  Well, except for that pesky Excel again. It evaluates 2^3^2 to be 64 instead of 512.

In fact, the only spreadsheets that I've found so far that give 512 are Google Sheets and Gnumeric on Linux. Gnumeric is even kind enough to automatically insert parentheses to explicitly show 2^(3^2) as well as (-2)^2.

So, a few spreadsheets do -2^2 correctly and a few do 2^3^2 correctly, but I'm not aware of any spreadsheets that do both of these operations correctly.

It's sad that developers are so careless.
Here's a quote from the XLS format specification:

Quote:With the exception of control tokens (section 2.2.2.3), display tokens (section 2.2.2.4), and mem
tokens (section 2.2.2.5) that are described in subsequent sections, parsed expressions are stored in
Rgce (section 2.5.198.104) using Reverse-Polish notation.

So it's clear that Excel uses RPN to store and evaluate expressions. This means that OpenOffice, Gnumeric, etc. could choose the other convention without breaking compatibility with existing spreadsheets (since existing expressions are pre-compiled to RPN, there's no ambiguity!!). They could simply open an old spreadsheet written with Excel and the same formula would display (-2)^2 under the "correct" convention, but will always give the same result of 4. When the user types -2^2 on a new formula, give -4. When you go back to Excel and open that file, Excel will display -(2^2) (under the "wrong" convention) and keep giving the -4 result you got before. Nothing really breaks, so I don't understand their reasoning.
Same thing for the associativity of exponents.

Claudio

[Marcus von Cube]

XLSX stores formulas as text... No preconpiled RPN expressions whatsoever in recent versions of the Excel file format.

[David Hayden]

I'll start by saying that I agree that -2^2 should be -4.

Now some philosophical thoughts. It seems to me that the problem is that we use "-" for at least 3 different operations:

1. subtraction: a - b
2. unary minus: -x is shorthand for 0-x
3. specifier for negative numbers: -5 is a number on the number line.
   

The last one may require some explanation: I'm saying that in this case, the "-" is part of the number, not an operation. The same is true of the decimal mark: in "5.2", the "." isn't an operation, it's part of the way we specify the number itself.


To see the difference, consider the following on a 50g:

Code:

X [ENTER] 5 [+/-] -   ---> 'X--5'

In other words, this is the variable X minus a real number (negative 5)

Or the strange case where sometimes numbers must be enclosed in parenthesis:
5 X Y^X [ENTER] -> '5^X'
5 [+/-] X Y^X [ENTER] ---> '(-5)^X'

This means that decompiling symbolic expressions is hard: negative numbers decompile differently depending on the operations they're involved in.

All of this would be easier of we used different symbols. Suppose:

• negative numbers are specified with prefix "n". e.g. n5 means -5
• subtraction is the negative sign: -
• unary minus is "um"
  

Now nX^2 isn't a valid math expression. Neither is -X^2 since "-" is a binary operator. umX^2 is the original problem. This is NOT subtraction, so its precedence isn't specified by the PMDAS rules. Mathmatically, it would seem to come between Multiplication/Division and Addition/subtraction, so school children would be taught PMDUAS.

What about 4-2^2 vs -2^2+4? In the new notation it's clear that you're using different operations here: 4-2^2, 4+n2^2 and 4+um2^2 are all different expressions (the latter simplifies to 4-2^2).

[Les Bell]

All the above just reinforces my love for RPN. My calculators are never in any confusion about what I mean.

[Don Shepherd]

(07-24-2014 04:11 PM)David Hayden Wrote:  school children would be taught PMDUAS.

Please excuse my dear unmarried aunt Sally?

Poor kids!

[Eddie W. Shore]

-8^2 returns -64 but -8 * -8 returns 64:

-8 * -8
(0 - 8) * (0 - 8)
—8 * —8 // — used as a negative sign.
—1 * 8 * —1 * 8
64

I don't recall any calculator manual mentioning that the [ - ] really meant unary subtraction. That key was always labeled negation. Thankfully, manuals do state that this operation is executed after powers and roots in the order of operations.

We also have the problem of inverse functions. Clearly, when the user presses [ - ] [ 8 ] [x^2], the user was not intending to enter an imaginary number. But on software with algebraic entry:

-8^2 returns 64
SQRT(Ans) returns 8*i or Error if complex mode is turned off or not available.

Personally, I prefer if [ - ] just negates the number and make it part of the number.

[Matt Agajanian]

I’m just going to throw this out there. What if instead of using the standard/de-facto dash for both minus & unary minus, using a superscripted dash or even overline (opposite of underline) or maybe even underline for a number intended as a negative number?

[Thomas Okken]

This is how the Taylor series for the sine is shown in Wikipedia:

$$\huge \sin x = \sum_{n=0}^\infty \frac{(-1)^n}{(2n+1)!} x^{2n+1}$$

It is shown the same way in every math textbook where I have ever encountered it.

The parentheses around the -1 indicate that the minus is not considered to be part of the number, but rather as an operator having lower precedence than exponentiation.

Of course it is always possible to invent new notations, but for this specific issue at least, I'd say chances of such an innovation being widely adopted are ε.

[mfleming]

(06-01-2024 02:19 PM)Thomas Okken Wrote:  Of course it is always possible to invent new notations, but for this specific issue at least, I'd say chances of such an innovation being widely adopted are ε.

In APL the "high minus" or overscore is an integral part of the definition of a negative number, not a function separate from the number. Other languages or notations (APL is both) can probably also be cited.

In support, few processors that I'm aware of store numerics as strictly positive values and require a negation operation in a calculation, though there may be a remote chance that one exists*

* Brownie points to anyone who can name one.

[Thomas Okken]

(06-01-2024 08:12 PM)mfleming Wrote:  In support, few processors that I'm aware of store numerics as strictly positive values and require a negation operation in a calculation, though there may be a remote chance that one exists*

That's not really an issue, though. For example, in Plus42, at one point I added explicit support for negative numbers, simply by adding a special case for the code generation logic for unary minus, where it checked whether the argument was a literal, and transformed that literal into its negative, before emitting the executable code. (I never released that optimization because it made the correspondence between source code and generated code in TRACE mode too confusing for my taste, and the performance benefit was too tiny to be worth it.)

So, for example, -2 would be parsed as unary_minus(literal(2)) and then optimized to literal(-2). Doing the optimization after parsing was what made it safe: -2^2 is parsed as unary_minus(pow(literal(2), literal(2))), so now the unary_minus(literal(X)) to literal(-X) won't be performed, because the pattern doesn't match.

Separating optimizations like this from the language that the user writes in is part of what compilers are supposed to do.

[dm319]

(06-01-2024 02:19 PM)Thomas Okken Wrote:  Of course it is always possible to invent new notations, but for this specific issue at least, I'd say chances of such an innovation being widely adopted are ε.

Agreed, this is standard mathematical algebraic notation and the closer a calculator tries to represent it, the closer to real maths it should behave.

Throughout the history of calculators we've started with a poor representation of algebraic notation and steadily improved, with early calculators having no concept of the order of operations. The exponentiation or square button on older algebraic calculator simply applied that function to the number in your x register. It was not trying to represent -x².

Much like the other viral 'ambiguity', the trap is looking to calculators, spreadsheets and programming languages to give us the answer when the notation was established hundreds of years prior.

This guy explains it well https://dotnet.social/@SmartmanApps/112353831654372246. He also has something to say on 'unary' too.

[Steve Simpkin]

(06-02-2024 08:22 AM)dm319 Wrote:  

(06-01-2024 02:19 PM)Thomas Okken Wrote:  Of course it is always possible to invent new notations, but for this specific issue at least, I'd say chances of such an innovation being widely adopted are ε.

Agreed, this is standard mathematical algebraic notation and the closer a calculator tries to represent it, the closer to real maths it should behave.

Throughout the history of calculators we've started with a poor representation of algebraic notation and steadily improved, with early calculators having no concept of the order of operations. The exponentiation or square button on older algebraic calculator simply applied that function to the number in your x register. It was not trying to represent -x².

Much like the other viral 'ambiguity', the trap is looking to calculators, spreadsheets and programming languages to give us the answer when the notation was established hundreds of years prior.

This guy explains it well https://dotnet.social/@SmartmanApps/112353831654372246. He also has something to say on 'unary' too.

The following Datamath page describes the long evolution that TI had with algebraic entry on their calculator models.
http://www.datamath.org/Sci/WEDGE/SR-52_...ing_System:

[dm319]

(06-02-2024 10:24 AM)Steve Simpkin Wrote:  The following Datamath page describes the long evolution that TI had with algebraic entry on their calculator models.
http://www.datamath.org/Sci/WEDGE/SR-52_...ing_System:

Thankyou for sharing, I never quite understood the logic behind the += and -= operators, but I guess I need an adding machine to get that context.

[KeithB]

"I’m just going to throw this out there. What if instead of using the standard/de-facto dash for both minus & unary minus, using a superscripted dash or even overline (opposite of underline) or maybe even underline for a number intended as a negative number? "

You mean like the Prime?

(unary minus)2^2 is still -4.

[Steve Simpkin]

(06-03-2024 07:24 PM)KeithB Wrote:  "I’m just going to throw this out there. What if instead of using the standard/de-facto dash for both minus & unary minus, using a superscripted dash or even overline (opposite of underline) or maybe even underline for a number intended as a negative number? "

You mean like the Prime?

(unary minus)2^2 is still -4.

Unless you are using RPN entry mode. Then the square of -2 is 4.

[Johnh]

Of course it's all a matter of conventions, established by mathematicians over hundreds of years. So my view as an engineer is irrelevant:

But, when I see that -2 at the start of an expression, my view is its not expressing that we have subtracted 2 from 0, even though it's the same value -2 is a digit, like 0 or 2 or 123. We need it as such, and in complex numbers we need the imaginary negatives too. Digits must take priority. The problem is we use the same symbol for subtraction as for negative numbers. So we need a convention, or brackets to clarify.

We can write 1 + -2, and we know what we mean, its -1 The same should apply to -2 + 1, and also 3 x -2 = -6, then so does -2 x 3. We should be able to extend to things like exponents too. Eg, the square root of -9 needs to be 3i, not -3.

In practice, despite any convention, all real world systems and written expressions should have enough brackets etc, so that any of these discussions and anomalies are bypassed.

And isn't RPN great! how it just jumps so cleanly over all these issues!