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...
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...
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.
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.
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.
avoids this entirely.
or if you wanna be really fkn nerdy:
∕, instead of /
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.
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...
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.
(* (/ a b) c)
and not: (/ a (* b c))
It's very ambiguous, though. No scientist would ever write expressions like that. 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.
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