[unanimous]

SpeedCrunch looks very promising, and I've used it a lot in the past. I'm sad to see that they still haven't released the order of operations bug fix [0] they made in 2017.

SpeedCrunch does some operations in an order most people wouldn't expect. For example, SpeedCrunch says 1/2(-9.8) = -0.05102040816326530612

[0] - https://bitbucket.org/heldercorreia/speedcrunch/commits/ac49...

[kragen]

You could make 1/2x where x = 4 evaluate to either 2 or 0.125, but either choice will have surprising results in some cases or to some people. Perhaps a better choice, especially for an interactive calculator, is to adopt partially ordered operator precedence, and reject the expression as ambiguous. Then the user can insert parentheses to disambiguate.

In a CFG this is easy enough to express. Here's an untested and at any rate incomplete CFG demonstrating the technique:

    expr ::= term | term "+" expr | term "-" expr
    term ::= quotient | product
    quotient ::= atom "/" atom | atom "/" quotient
    product ::= atom product | atom "*" product | atom
    atom ::= number | variable | "-" atom | "(" expr ")"

But typical parser generators don't give you an easy way to provide a useful error message there.

That version of the grammar, btw, avoids left recursion, so it ought to work as a PEG, but at the cost of the wrong associativity for "/" and "-". You either need to use left recursion or restructure the syntax tree afterwards.

[darkwater]

> You could make 1/2x where x = 4 evaluate to either 2 or 0.125

Ouch, you just made me think that if I see this equation just "horizontally" like it's presented here, I would say 2. But if I imagine it like you would write it on paper, I would answer 0.125.

[TchoBeer]

The solution is to differentiate between 2*x and 2x. / would have higher priority than *, but lower priority than conjunction

[kragen]

That is a thing you can do, and for example units(1) does just that, but doing it creates the usability problems we are discussing in its thread. My comment is aimed at solving those problems, not worsening them.

[megapatch]

This is why it is much more natural to use RPN. Solves all these problems: 1 2 / -9.8 * Or 1 2 -9.8 * /

[seanw444]

Is that not correct? I guess I should touch on my order of operations. I thought distributing was part of the parenthesis step, that came before MDAS.

[kstrauser]

The disconnect is that a lot of people mentally treat implicit multiplication with a higher priority than explicit, which is pretty understandable. For instance:

  1/3x

is likely to be understood as 1/(3*x), because otherwise it would’ve been written like x/3. If that’s true, then so surely

  1/3(x) 

should be the same, right?

Smarter people than I have argued both sides of this, and I don’t have a strong opinion except to use parentheses if there’s any possible ambiguity. Just saying, I totally understand why you’d come to that conclusion, and I probably would too.

[spsful]

The part that confuses me is why someone would think the SpeedCrunch implementation is correct:

Say again that you have 1/3x. This is implicitly stating 1/3x. However, no parenthesis are used, and multiplication & division are on the same level in the order of operations, so the expression gets evaluated sequentially from left to right.

If you have 1/3(9.8), evaluating the parenthesis gives you 9.8. So you now have 1/39.8. The expression inside the parenthesis gets evaluated first, then the final result is just multiplied by whatever precedes or succeeds the parenthetical if no other term is given. So 1/3+(9.8) would obviously evaluate to be 1/3+9.8.

Again, if the parenthesis aren't enclosing operations within themselves, then they shouldn't modify the way you'd evaluate the expression. I've had this problem with SpeedCrunch many times over and wish they would update it. Still the best desktop calculator IMO.

edit: a word

[zestyping]

Implied multiplication (with no operator) has a higher precedence than explicit multiplication (with an operator). Most mathematicians see it this way.

[bee_rider]

Really though, order of operations is just a convention. Practically, I'd think of PEMDAS as descriptive rather than proscriptive (nobody is going to revoke your math license if you and your friends violate PEMDAS together). Frequent topics of debate or confusion seem to indicate a edge case in the living convention. Therefore, I think you are smarter than either of the debaters if you stick with the parentheses.

[danbruc]

I would be confused if 1/2gt^2 would mean anything but 1/2 g t^2 and 0.5 g t^2. 1/3x in isolation may look a bit unusual, but with context the choice between 1/3 x and x / 3 may actually convey additional information, information about the structure of the calculation. Manipulating an equation into some kind of normal form may lose information.

[commoner]

Yes, that answer is incorrect since it breaks with calculator conventions. The contents of the parentheses are calculated first (P in PEMDAS), and then the multiplication is done later (MD in PEMDAS). Implicit multiplication (which does not explicitly use a multiplication sign) has the same priority as any other multiplication:

  a/b(c) = a/b*c = (a/b)*c

Since SpeedCrunch only accepts input in a single line, this would be the least unexpected way to interpret the expression, and consistent with how graphing calculators operate.

A horizontal fraction bar, which SpeedCrunch does not support (since it only accepts single-line input), implies parentheses around the numerator and denominator. For example:

  ax
  -- = (ax)/(by) = (a*x)/(b*y)
  by

compared to

  ax/by = a*x/b*y = ((a*x)/b)*y

(If the above is not displayed correctly, please view this comment on the HN website.)

Implicit multiplication is a point of frequent confusion:

- https://www.nytimes.com/2019/08/05/science/math-equation-pem...

- https://www.themathdoctors.org/order-of-operations-implicit-...

To guarantee that the expression does not get misinterpreted, the person writing the expression should always add parentheses/brackets and explicit multiplication signs, or use horizontal division bars where possible, to make the expression unambiguous.

[Measter]

Not even calculators agree on this. Here's a picture of my Casio fx-83ES and fx-83GT calculators giving different answers to "8/2(2+2)": https://i.imgur.com/SsKUQrE.jpg

Both answers are completely, 100% correct according to the operator precedence table in their manuals. I also have a Casio fx-83MS and fx-991ES, both give 1 as the answer.

Others I have are a Casio fx-570CD and a Casio statistical calculator I don't remember the model of, neither of which support implicit multiplication, and a SwissMicros DM42, which is RPN and doesn't have to deal with operator precedence.

I don't even know why I have half of these...

[sbuttgereit]

Looking at this issue and then trying Qalculate! as some of the other commenters to this post have mentioned.... I tried 1/2(-9.8) and it calculated it as -0.05102040816 as I was doing the entry. As soon as I hit enter, however, it popped open a dialog box saying "The expression is ambiguous" and asked me to select an interpretation of expressions with implicit multiplication, setting a preference for later use. The choices were:

Implicit multiplication first: 1/2x = 1/(2x); Conventional: 1/2x = (1/2)x; Adaptive: 1/2x = 1/(2x); 1/2 x = (1/2)x

So their answer is to just ask the user what to do! It won me over with that.

[commoner]

That's the perfect way to deal with this case. I've been using Qalculate! for quite some time, but never saw this dialog because I've apparently never entered an ambiguous expression before. Thanks for sharing this.

[commoner]

I have to say, it's really disappointing to see similar models from the same brand act differently. Thanks for testing this out and shedding more light on this issue.

[Jerrrry]

÷ https://en.wikipedia.org/wiki/Division_sign

avoids this entirely.

or if you wanna be really fkn nerdy:

∕, instead of /

[teawrecks]

Almost every one of those Facebook reposts with an ambiguous math equation features an obelus. It only seems to create confusion.

[commoner]

You're right. The division sign is also unambigious. Unfortunately, it's not usually found on keyboards so many people are accustomed to using slashes.

SpeedCrunch and other calculator apps still need to have an unambiguous way of interpreting the expression when the user types or pastes in a slash. The apps could convert slashes to division signs before displaying them on the screen, since that's how the symbols should be interpreted. This is how GNOME Calculator resolves the ambiguity.

[NavinF]

Nobody uses that symbol after grade school.

[qsort]

According to the mainstream interpretation, a/b(c) parses to:

    (* (/ a b) c)

and not:

    (/ a (* b c))

It's very ambiguous, though. No scientist would ever write expressions like that.

[trasz]

It’s a question of whether the above is supposed to mean (1/2)(-9.8), or 1/(2(-9.8)). Technically it’s ambiguous (I think), in practice it’s obviously the former, because if it was the latter you’d write it as 1/(2-9.8).