I find myself absentmindedly typing out math 220*1024*1024 while talking to people in meetings (what, you don't have meetings where it's crucial to know how quickly 220MB can be transferred?) and like thousands of other situations. It has all the precision you want, as long as you only want results up to the 4th decimal. I even use it in other shell scripts, since bash's math facilities are rather limited and inconsistent across sh vs bash. It just yeets all its arguments into bc -l, so you can run math 1+2-3 or math '(1024 - 7)*10' or whatever else you want. Scale=4 # results will print to the 4th decimal Please let me interactively choose them without fiddling with cursor movement commands.’Ī small plug for my own script: I'm proud to present the most useful, least-work script I've ever written: `math` I’d like to see something that let you place a ‘(‘ somewhere ‘backwards’, or in other words a feature for ‘I would like to parenthetical use some of the past expressions. I think gnu Calc is lacking a bit in entry of algebraic expressions but I don’t think speed crunch is better. Display-style (‘big’) presentation is optional but ugly ascii art. GNU Calc has most of these (+ and * are still shifted but all common operations are shifted. specialised shift operators which mostly meant inverse or hyperbolic single (sometimes shifted) buttons for functions like cos/tan/arcsin/… display-style input of fractions and exponential so you got some visual clue if your brackets weren’t totally wrong single buttons for common operations like +, * or sqrt The calculator I used in school was infix but, unlike this calculator, had: 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. 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 Comments
Leave a Reply. |