Wrong evaluation of powers involving unary minus sign in base

[Former user]

Originally reported on Google Code with ID 160

Reported by Alberto Luaces - aluaces udc es - on Debian Bug Tracking System
as issue #469468:
-----

Some speedcrunch results:

-9^2 = -81
(-9^2) = 81

It seems the program is reading incorrectly prefixed minus signs when found
between parenthesis. It leads to incorrect results on more elaborate
expressions as

0.73+(-0.73^2+1.065^2)/(2*0.73)

SpeedCrunch version: 0.9

Reported by helder.pereira.correia on 2008-03-05 12:56:41

[Former user]

``` the precedence of unary operators is always highest now. Annoying: -1^2 should best be parsed as -(1^2), not (-1)^2, as it is now. This can't be fixed easily in the old parser code, but at least the parser works in a predictable way now. ```

Reported by `wolf.lammen` on 2008-03-21 16:06:21

[Former user]

Reported by `helder.pereira.correia` on 2008-03-22 19:56:13 - Status changed: `Started` - Labels added: Milestone-0.11 - Labels removed: Milestone-0.10

[Former user]

Reported by `helder.pereira.correia` on 2008-07-19 18:24:29 - Labels removed: Milestone-0.11

[Former user]

``` Issue 327 has been merged into this issue. ```

Reported by `helder.pereira.correia` on 2010-02-07 08:34:21

[Former user]

``` Issue 326 has been merged into this issue. ```

Reported by `helder.pereira.correia` on 2010-02-07 08:40:10

[Former user]

``` Guys, please stop distributing _broken_ software. It's trivial to find error in -x^2, but *it is not* in things like "a / ln( b / exp( -x^2 / c ) )" or more complex. It hits very hard. ```

Reported by `alek.silverstone` on 2010-02-07 13:14:59

[Former user]

``` Also this means that -x^2 ≠ 0 - x^2. Great. ```

Reported by `alek.silverstone` on 2010-02-07 13:15:50

[Former user]

``` The expectations of people differ with regard to proper precedence among unary - and ^ [in fact, more than a few are not familiar with the concept of precedence at all, and expect a formula to be evaluated strictly from left to right], and there are well-founded reasons for either opinion. For example, the current implementation renders the sign (as in -1) always part of a constant, which is quite a natural view. Since SpeedCrunch somehow has to arrange the terms in an expression, one solution must be preferred, and THIS SOLUTION IS DOCUMENTED IN ITS MANUAL. So kindly explain in what respect the software is BROKEN, then?? It certainly does not match your expectation, it might not comply with some broadly accepted standard in a particular corner case [yet to be shown], but it BEHAVES EXACTLY the way it is described to run. There is a simple solution, that you should adhere to: IN ALL CASES OF DOUBT: ENFORCE A PARTICULAR EVALUATION ORDER BY USING PARENTHESES.

Wolf ```

Reported by `wolf.lammen` on 2010-02-07 14:36:47

[Former user]

```

in fact, more than a few are not familiar with the concept of precedence at all,

and expect a formula to be evaluated strictly from left to right

I truly believe you do not create this software for this folks.

THIS SOLUTION IS DOCUMENTED IN ITS MANUAL

Ok, what if for every expression SC will return random result? You will still say "It's documented feature?"

software is BROKEN

Yes, it's broken. Just because it confronts with _mathematics_ and _common sense_.

It certainly does not match your expectation

Ah, right. Everyone have it's own maths…

IN ALL CASES OF DOUBT: ENFORCE A PARTICULAR EVALUATION ORDER BY USING PARENTHESES

Just like old good C macros:

1. define L(x, y) sqrt((x)^2 + (y)^2) ```

Reported by `alek.silverstone` on 2010-02-07 14:52:53

[Former user]

```

For example, the current implementation renders the sign (as in -1) always part of

a constant, which is quite a natural view.

Not just for constants: x = -1 -1 -x^2 1 ```

Reported by `alek.silverstone` on 2010-02-07 15:05:08

[Former user]

```

I truly believe you do not create this software for this folks.

It is not designed for experts- and mathmaticians-only, either.

Let's continue with citations from Wikipedia:

Unfortunately, there exist differing conventions concerning the unary operator −

(usually read "minus"). In written or printed mathematics, the expression −32 is interpreted to mean −(32) = −9, but in some applications and programming languages, notably the application Microsoft Office Excel and the programming language bc, unary operators have a higher priority than binary operators, that is, the unary minus (negation) has higher precedence than exponentiation, so in those languages −32 will be interpreted as (−3)2 = 9. In any case where there is a possibility that the notation might be misinterpreted, it is advisable to use parentheses to clarify which interpretation is intended. <<

Different calculators follow different orders of operations ... << Many programming languages use precedence levels that conform to the order

commonly used in mathematics, though some, such as APL or Smalltalk, have no operator precedence rules (in APL evaluation is strictly right to left, in Smalltalk it's strictly left to right).<<

Ah, right. Everyone have it's own maths

Like it or not, this seems to be the real world. And I'd like to add: 'common sense' might be quite different from your personal assumptions!

Ok, what if for every expression SC will return random result? You will still say

"It's documented feature?"

Exactly. It would render SC useless, but if it had been designed to work so, that's what you should get. There are semantic differences between 'broken', 'non-standard' or simply 'not matching the expectation of what I think is a majority of users'. To be precise: I, one producer of this software, promise to the interested, that SC works the way described in its manual, and you, the user, accept this contract by using this software. Feel free, not to do so, but do not rant, if you did not RTFM, and something goes wrong then. So I continue to state: this software is NOT BROKEN.

That all said, I do not think it works the best way possible [which would be a configurable design, btw] (see my first posting here). However, I'd rather hear from you something like "I suggest to change the evaluation rules in the following respect to be more along lines of standard XY" than "Immediately stop spreading your broken software!"

Wolf ```

Reported by `wolf.lammen` on 2010-02-08 10:27:37

[Former user]

``` Thanks for all the great replies, Wolf. Essentially, this discussion has the same nature as the one about comma vs. dot. And ideally, we should support both unary conventions in a configurable way.

But @alek.silverstone: I think you should read http://speedcrunch.blogspot.com/2008/08/essential-motivation-in-free-software.html that I wrote 1,5 years ago. I'll sum it up for you: either contribute to the project if you know how to do it technically speaking (and you seem to), or report/discuss its limitations/mistakes in a respectful and intelligent way. Or even better, you can pay us a salary to fine tune the application for your own purposes, and really quick. ```

Reported by `helder.pereira.correia` on 2010-02-08 22:00:28

[Former user]

``` @everyone I doesn't have time to read this blog post right now, but I know that I was too much angry. As I told, this "documented bug" hits hard. I was forces to recalculate large work for university. And I _still_ believe that mathematics is one for everyone. If MS Office have wrong priorities, it's still wrong. I just should be more polite.

Regarding implementation… Again, doesn't have time to check it now, but how about remove unary operations from parser completely? For example, replace "-x^2" with "0-x^2" at the very first stage? This should work, and it doesn't sounds hard to implement.

btw, comma vs. dot is all about locales, doesn't it? ```

Reported by `alek.silverstone` on 2010-02-09 05:03:03

[Former user]

``` There's something, that could be related. I found it when running testevaluator (which is way out of date, btw; it's such a great tool for testing!). I got 56 errors and this one among them: "ABS(-1/-2)" Result: -1, Expected: 0.5 so I tried in the GUI: "1/-2", result: -1 "1*-2", result: -1

I suggest to change the evaluation rules, if I may :) Using devel version, last commit: 8f8d36878a89d3844c1f12ba944cc7fc1eed6228 ```

Reported by `wesand` on 2010-06-16 13:23:45

[Former user]

``` Also, there's more about "-" sign. Take a look at the expression: "1--1". 1. C++, python, Qalculate evaluates to: 2 2. PHP, bc gives an error (accepted form: "1-(-1)") 3. SpeedCrunch evaluates to: 0 (looks like "--" is `compressed` into a "-")

I think SpeedCrunch is wrong in this case. Maybe (2.) would be an easy and quick way to fix. ```

Reported by `wesand` on 2010-06-16 13:56:43

[Former user]

``` Issue 372 has been merged into this issue. ```

Reported by `helder.pereira.correia` on 2011-02-22 23:07:38

[Former user]

``` Issue 391 has been merged into this issue. ```

Reported by `helder.pereira.correia` on 2011-11-27 01:55:04

[Former user]

``` Same bug in

0.10.1 on Linux

I know that in computer science the "-" sign has the ambiguous significance of operation or part of the number, but in maths there is no ambiguity, the expression -4^2 MUST be interpreted as -(4^2) NOT (-4)^2

This is not a dispute between computer experts vs mathematicians, this is the maths that ALL common people learn at school.

RTFM in this case sounds like "this is my software and it gives the results I want, not the ones people expect" ```

Reported by `nicolabarbini` on 2012-01-06 12:10:19

[Former user]

Fixed in revision e6c37b90

Reported by helder.pereira.correia on 2013-10-12 06:41:48 - Status changed: Fixed - Labels added: Milestone-0.11, OpSys-All

[Former user]

Issue 449 has been merged into this issue.

Reported by helder.pereira.correia on 2013-10-12 07:46:00