Implicit multiplication is a point of frequent confusion: (If the above is not displayed correctly, please view this comment on the HN website.) 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.Ī horizontal fraction bar, which SpeedCrunch does not support (since it only accepts single-line input), implies parentheses around the numerator and denominator. Implicit multiplication (which does not explicitly use a multiplication sign) has the same priority as any other multiplication: The contents of the parentheses are calculated first (P in PEMDAS), and then the multiplication is done later (MD in PEMDAS). Yes, that answer is incorrect since it breaks with calculator conventions. You either need to use left recursion or restructure the syntax tree afterwards. 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 "-". Product ::= atom product | atom "*" product | atomĪtom ::= number | variable | "-" atom | "(" expr ")"īut typical parser generators don't give you an easy way to provide a useful error message there. Quotient ::= atom "/" atom | atom "/" quotient Here's an untested and at any rate incomplete CFG demonstrating the technique:Įxpr ::= term | term "+" expr | term "-" expr Then the user can insert parentheses to disambiguate.
Perhaps a better choice, especially for an interactive calculator, is to adopt partially ordered operator precedence, and reject the expression as ambiguous. 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. but that's dead now.īut it's really neat to see how this all started from a day or two of hacking on a solution to a simple problem. I can't find Ariya's original 2004 announcement, I think the original link was. One of those was Ariya Hidayat's "SpeedCrunch", which has been actively maintained up to the present day. His blog post elicited several rapid responses from developers taking his PyQt-based mockup and turning it into a 'real' application (, ). Back then developers were often just unthinkingly cloning 'skeuomorphic' interfaces like Apple used back then, designing user interfaces that resembled physical objects instead of taking advantage of the opportunities afforded by computers. Fun fact about SpeedCrunch history, the software descends from an off-hand blog post by Roberto Alsina, a KDE developer, complaining about KCalc usability.
0 kommentar(er)
