I'm having a hard time taking this bug's severity seriously. Firstly, it's not uncommon for very cheap calculators (especially old ones) to evaluate each operation immediately[1][2]. Doing order of operations requires ram to store pending expressions. Doing order of operations in a usable manner also requires paren keys to override the order, and a display to show the expression. Otherwise you're just typing blind and hoping that the calculator happens to do the right thing, even with order of operations.
Which brings me to my second point, which is that a calculator is a tool, and it's up to the user to use it correctly. I would never rely on any random new calculator like this to get the order right, so I'd always feed it simple expressions in the correct order anyway, and press = after each, and so no matter what arbitrary ordering or lack of ordering the calculator happens to use would't matter. So I'd be more concerned with calculators dropping precision at the number of digets that can be displayed, and other issues noted in this bug report than this OoO issue, and I don't think it's RC. (#debian-release seems to agree.) In closing, I can't belive you suckered me into typing so much about a program I'd never use. Go qalc! -- see shy jo [1] http://neirtec.terc.edu/ma/examples/10_example_p01.cfm?fromPage=../examples/00_toc.cfm&fromlabel=Classroom%20Examples "On the other hand, a classic four-function calculator computes values without regard to the algebraic order of operations, typically completing computations as numbers and operations are entered." [2] http://en.wikipedia.org/wiki/Order_of_operations "Different calculators follow different orders of operations. Cheaper caculators without a stack work left to right without any priority given to different operators [...] while more sophisticated calculators will use a more standard priority Microsoft's calc.exe program uses the former in its standard view and the later in its scientific view."
signature.asc
Description: Digital signature
