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
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.
> 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.
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.
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.
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.
Implied multiplication (with no operator) has a higher precedence than explicit multiplication (with an operator). Most mathematicians see it this way.
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.
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.
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:
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.
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.
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:
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.
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.
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.
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).
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...