Just putting it out here - before the recentish redesign of ios's default calculator, it had a <i>widely</i> non-intuitive behavior. Due to how it looked I assumed it works as a standard four-function calculator, but it was actually storing the whole expression in memory and executing it as per the standard precedence rules.<p>I do usually prefer the latter behavior, but without it being displayed as in more advanced calculators (it has been changed to show it) it's just not what I would expect at all, resulting in wrong calculations. But maybe it was just a "me-problem".
I realised reading this that, even though I used to be quite adept with these common four-function calculators, I have since forgotten most of their operation. The past ten years or so I have exclusively been using RPN calculators – I find them so much easier to work with, and going by this article, possibly even easier to implement sensibly?<p>(My main drivers are Emacs Calc on the computer and RealCalc on Android devices. For kitchen work I use a slide rule, which is something I think more people should do! There is nothing better for translating proportions.)
If anyone else was curious about the final image and the `x÷` button: <a href="http://www.vintagecalculators.com/html/sharp_el-8.html" rel="nofollow">http://www.vintagecalculators.com/html/sharp_el-8.html</a><p>----<p>> The keyboard on this calculator has the number of keys reduced to the minimum by the use of only three function keys, including a combined "x÷" key.<p>> Here, pressing "x÷" gives the multiplication function if "+=" is subsequently pressed to give the answer, and gives the division function if "-=" is subsequently pressed to give the answer, so:<p>> 4 x÷ 2 += gives the answer 8.<p>> 4 x÷ 2 -= gives the answer 2.
Reading this article and the thought process behind it reminds me of this almost-10-year-old comment I made about how they actually work: <a href="https://news.ycombinator.com/item?id=9456444">https://news.ycombinator.com/item?id=9456444</a><p><i>Selecting an operator loads this value into the accumulator and makes room for the second operand to be typed in.</i><p>Here is where I think the first mistake was made; if you observe the effect of repeatedly pressing '=', that obviously does not clear any registers, but merely repeats the last operation.<p><i>But there’s more to the story: it’s actually a side effect of a little-known “K-constant” feature that retains one of the previously-entered operands and the operator, and lets you vary the other operand.</i><p>I haven't used any 4-function calculator that behaves like this; instead, I get (without clearing):<p><pre><code> 2 + 1 0 = 12
5 = 22
0 = 32</code></pre>
This article makes it sound more complicated than it is, collecting all those edge cases. Many of them can be simply ignored, as in being no-op. Which is also what most cheap calculators do...
> Let’s start with the basics: the simplest calculator has ten digit keys, a decimal dot, four arithmetic operators (+, -, ×, ÷), a result button (“=”), and a “C” key to reset state.<p>Mathematically there is already quite a lot happening here and in addition (pun) we use base-10 representation of numbers, which is not the simplest.<p>Might be interesting to explore if decomposing the problem into even simpler "sub-calculators" (e.g., starting with binary addition) and then putting everything back together as a sort of <i>progressive enhancement</i> would reveal the most logical or economical UI.
To this day I can not remember which is which in calcs with clearing buttons. I know probably one of them clears the operator and the other clears the whole operation, but since I'll never figure out the correct one I just start pressing everything when I want to start over and hope.
I'm not joking when I say I'm 30 and I still don't understand how to use a calculator without a proper display where you see the entire expression to be evaluated. At school in the UK we all had calculators where entire expressions could be typed in including proper fractions and parentheses. I find the more basic kind of digital calculators, including built-in calculator apps, to have totally impenetrable user interfaces
I think calculators should have "into" and "from" so you can do division and subtraction on the previous result without retyping it. I made a demo: <a href="https://fluent-calc.vercel.app/" rel="nofollow">https://fluent-calc.vercel.app/</a><p>Also supports saving a result into a variable for later reference, and x "as proportion of" y, which is just an alias for division.
This is why every calculator ever should have a RPN mode. Postfix notation removes all of that parsing ambiguity.<p>I ended up making my own RPN calculator in C++/Dear ImGui because I wasn’t happy with any of the options for desktop Linux and, implementation wise, RPN is dead simple. Grab values off the stack, apply operator, push back onto stack.
Oh, it doesn't even get to the juicy bit of percentages.<p>Can't remember how physical calculators deal with them, but software calculators deal with them differently.<p>To the point that iOS calc and MacOS calc are different. And variations of Windows calc (regular/scientific/engineering) are different
I remember fondly having figured out how to implement precedence with two stacks, one for operations and other for operands, the same way my Texas Instruments calculator did.<p>It is possible to implement a desktop accessory calculator in a lunch break, but only because you get a whole lot of abstraction done by the GUI environment. Modelling the UI as a state machine in this case is essential so you don’t get crazy with all the corner cases.
Simple calculators are actually a bit like functional pipes.<p>There's no precedence. Everything is left or right. Every button is a prefix command: OP ARG or else just OP.<p>For instance 3 + 4 x 3 - 1 x 9 - can be evaluated in a particular Lisp dialect as<p><pre><code> (lflow 3 (+ 4) (* 3) (- 1) (* 9) -)
</code></pre>
Where lflow is a left inserting pipe operator. It begins with the value 3, inserts it as the left argument into (+ 4) to actively produce (+ 3 4) and so on.<p>In the calculator, the result of the previous operation is similarly another argument to OP, which is inserted on the left. It can be understood as being held in an accumulator register.<p>If OP requires ARG, the evaluation doesn't occur until another OP is entered, or else the = button, which roughly means end of ARG. But OPs that take no argument other than the accumulator dispatch immediately. When OP ARG is followed by multiple =, it is repeated that many times.<p>When an ARG is entered not preceded by an OP, it replaces the accumulator.<p>In some calculators, when a new ARG value is entered this way, followed by =, the value is somehow substituted to the previous operation and it is reevaluated, instead of just becoming the new accumulator.
I think there's something to be said for UX consistency even if it's "wrong" in some ways. To a first order, every basic calculator works exactly the same, and it's easy to use them all once you've learned how to use one.<p>In contrast, every microwave in the world has reinvented its own new system for entering a time, and added a bunch of extra buttons for useless fake features.
I think this just illustrates why hidden state is so difficult for the user. It's hard to replicate old calculators because it was poor UI that was making do with what was yet available.
"those cheap plastic rectangles hide decades of edge cases, quirks, and questionable design choices. Want to change a number's sign? That's a special case. Chain operations? Special case. Divide by pressing equals repeatedly? That's a feature called K-constant, except multiplication plays by different rules because... reasons. By the time you've handled every possible button combination, you'll wish you'd stuck to programming smart fridges"
The intrinsic hardness of UI programming is representing state and state transitions. OP's problem would be much easier in a full language with things like structs and dynamic lists, but it still wouldn't be trivial<p>People sometimes miss the point and think of UI dev as painting pictures with code, which is part of it, but the hard part is state
Google's calculator on Android is an absolute shitshow. Sorry for omitting details, but this issue is easy for anyone to repro without any specific steps.
TL;DR PEDMAS is bullshit<p>If you look at the internal state of the typical physical calculate it's a beautifully simple machine that tries to catch the balance between RPN and logic... except it has stupid nonsensical human rules interjected.<p>So, every time this article where points out "actually it's more complicated than it seems" is where historically somebody has made deliberate design decisions to do it 'the dumb way' even though it adds complexity, to force something unnaturally.<p>And what you end up with is something that's half intuitive, it's in between the two systems, but it's more complicated than it needs to be.<p>Please, I would much prefer device for RPN calculation, that follows consistent logic, rather than silly imposed rules.<p>4+7*3 etc.<p>or 4 7 + 3 * =<p>Where the latter is much closer to what we do in our heads and conceptually think about it.