Incorrect operator precedence

[sboukortt]

-5**2 should return -25 (exponentiation takes precedence over negation) but it returns 25 instead. Presumably, it’s erroneously interpreted as (-5)**2.

[Pulau-Komodo]

This is debatable. LibreOffice Calc and Google Sheets will also yield 25 for -5^2, and -25 for 0-5^2.

[ashugg]

This is debatable. LibreOffice Calc and Google Sheets will also yield 25 for -5^2, and -25 for 0-5^2.

It is debatable - kind of - because mathematical notation can often be written ambiguously, or it can handled "incorrectly" with an assumption made in good faith by the programmer.

I would have interpreted sboukortt's request as the square of -5. If the answer -25 was wanted, I would expect the input to be -(5**2). We don't have to debate how I'm wrong - my interpretation is based on my own assumption that we want the square of x where x = -5.

rink could state how it is interpreting the input, perhaps?

e.g.

> -5**2
25  [(-5)**(2)] (dimensionless)
> -(5**2)
-25  [-((5)**(2))] (dimensionless)
> 

Just a suggestion for consideration.

Alternately, the base assumptions of the code could be stated in the documentation.

[tiffany352]

I figure that -(5^2) is the most useful interpretation, because (-5)^2 will have the same result as 5^2 (the negation is redundant). This avoids the need for parentheses in the case where the output value is meant to be negative. The logic here changes a bit for the case of complex numbers, but Rink doesn't yet support those (maybe someday).

I have another PR open for showing input interpretation (#226), but I'll have to do a pass over it to make sure it inserts enough parentheses for disambiguation.

[Pulau-Komodo]

This ambiguity, like a few others I know, only exists because there just are no strong conventions for some cases. I would not call either interpretation wrong. Ideally you do whatever won't surprise people, but because other software will go either way, you will always surprise someone.

Outputting the interpretation, as suggested, is one possible way to alleviate the problem. Personally, I think it would be elegant to output whether something ended up being disambiguated or not. Then my front-end can warn the user in only those cases, making it more likely they will catch it if it went against their expectations. Perhaps the user can replace their input with the disambiguated version, or my front-end can offer to do it for them, to suppress further warnings.