UI is hell: four-function calculators
lcamtuf.substack.com
lcamtuf.substack.com
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".
The calculator built into Windows (at least back then, maybe they’ve changed it), gave 9 to my test instead of 7.
⸻
1. If they got some number other than 9 or 7, I recommended dousing it in holy water, and then gasoline, burning it, encasing the ashes in concrete and dropping that concrete block into the deepest part of the ocean because that calculator is cursed.
When I use a calculator, I don't necessarily care if I can punch in a written expression verbatim from left to right. I just want to do a calculation.
The UX is pretty clear - it's ANS operator newNumber. That's it, if not somehow displayed, then it shouldn't have a more complicated model inside either.
It can freely do "normal" math the moment they write out the whole expression tree, as the result of an expression is the one calculated by precedence rules. The result of a two-operand operation is not that, though.
Isn't that how even fairly cheap 'real' calculators do it now though or do really cheap ones really just do one operation at a time from left to right?
There were non-cheap calculators in the 1980s, too, that did proper evaluation. The ones I remember had keys for parentheses, though, allowing you to enter, for example
(3 + 4) * 7 =
For an example see the TI-25 at http://www.datamath.org/Sci/Slimline/TI-25.htm
Rotation changing how the calendar handled order of operations seems even less intuitive to me.
i'd assume that because the ui for the ios calculator app is the same as the ui of a cheap calculator. not sure i would ever consider the platform that app is running on.
Rotate it and the app was a basic scientific calculator.
(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.)
Even 15 years ago, you could type out an entire equation that would have to be used multiple times and just update a single part of it and hit enter and then scroll up, modify, and hit enter again. All of that without having to resort to keystroke programming.
RPN is easier to reason about, but in aggregate doesn't save much time when you have a really slick modern interface and can scroll around and see things pretty printed. In engineering it is common to have some crazy looking things that are just easier to reason about when you can see it matches what is on the paper in front of you.
For the most part the options are an older style RPN calculator (even the super nice swiss micros don't have equation scroll, although you can at least see the contents of the stack on the screen like the later HP calcs could), or what TI and Casio have.
Still a niche within a though. They weren't that common in the wild like the old HPs were. I knew someone in the engineering program at Texas Tech with a 50g, but never saw a single engineer or stem major at my school with one. They had them in production for awhile, so they're out there (logically speaking), but they've got to be a big outlier.
I have this sentiment every time I dive into some "other" programming math notation. Such as (lisp), rpn, infix without precedence, etc. In theory I like it, but then in practice it's just kind of painful.
We humans are entrenched in our bad but default notation!
I guess RPN has advantages for use as an input method for calculators, but as an actual algebraic notation? It seems to me it's very cumbersome to perform standard algebra on equations in RPN notation (or prefix notation, for that matter).
I can't be sure but as far as I know nobody has using anything other than infix for algebra. Every time I see a text explaining the advantages of RPN, it's always in the context of calculator input.
I haven’t found such an interface yet.
When you see a complicated, parenthesized expression, it's up to you to figure out the deepest expression, enter it first, and then work your way out.
Standard calculators require more keystrokes but they can be entered without much thought, left to right. And these days, you can also edit and modify your input, so it's hard to justify RPN.
If you have
1 + (2 * 3 + (4 / 5))
The smallest key count with RPN is to start entering the deepest expression first:
4 ^ 5 / 2 ^ 3 * + 1 +
You can type it left to right but it takes more keys and is probably on par with standard paren arithmetic, which negates the RPN advantage
1 ^ 2 ^ 3 * 4 ^ 5 / + +
https://www.swissmicros.com/product/dm41x
They also have their own versions of the 15c and so on. I have 3 different models (and one original HP RPN calc) and can confirm they are really high quality. Again though, spreadsheets are a lot more useful to me when I have more than just a simple calculation or two. I think these are mostly getting picked up by hobbyists, collectors, and those who work in labs and need a dedicated device with physical buttons.
Note that it doesn't have the big expansion pack things that I think the 41c came with if I'm thinking about the right calculator.
I have their DM42 and it feels good in the hands. The case is solid metal too and the screen is nice. I believe the performance is better than the originals (not hard as some of these were sold before my birth and I'm not exactly a spring chicken anymore) and they fixed several bugs.
Can someone show something useful in RPN? House odds on 3 on roulette, or don't come odds for 10; or the standard deviation of 1, 1, 1, 1, 7, 29.
I have never seen anyone show an example more complex than 2 2 12 + * or whatever it looks like.
You pay for that by having a stack rather than a small fixed number of variables.
you can easily add variables to your rpn calculator. For example ">x" pops the top of the stack into the variable x, and "<x" pushes the value of x to the stack.
You can also interpret parentheses as whitespace to enable users to group parts of the computation (but this may become confusing when they write nonsensical parentheses).
For example, I usually put 15 grams of coffee with 8 oz of water (please excuse the mixed units). To make a different amount, I align the 1.5 on the top rule with the 8 on the bottom rule to set the ratio. Then each number on the top rule (coffee in grams) matches the scaled value on the bottom rule (water in oz). The 6 on the bottom rule aligns with ~1.1 on the top, meaning I should brew my little six-ounce cup with 11g of coffee. In practice, I do this a lot with bread, but the "baker's percent" convention for writing bread recipes makes it a more complicated example.
Another way to use a kitchen slide rule is when scaling a recipe. Say I want to make 2/3 of a batch of cookies. I line up the 3 on top with the 2 on the bottom. Then for each ingredient, I find the recipe's quantity on top, and read off the scaled quantity on the bottom. This works better with recipes that use weights, to avoid awkward fractions or converting between units so you can subdivide.
----
> 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.
> 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:
> 4 x÷ 2 += gives the answer 8.
> 4 x÷ 2 -= gives the answer 2.
Then again…
I guess 4 += 1 += gives the answer 5.
What would be the result of 4 += 1 -= ?
Edit: the answer is “3”, elaborated on the linked page: http://www.vintagecalculators.com/html/calculator_keyboard_l...
4 -= 1 +=
4 -= 1 -=
I’m guessing 3 and 3?
4 –= 1 += gives: -3
4 –= 1 –= gives: -5
Manual for a similar model: https://www.oldcalculatormuseum.com/m-sharpqt8d.pdf
Selecting an operator loads this value into the accumulator and makes room for the second operand to be typed in.
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.
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 haven't used any 4-function calculator that behaves like this; instead, I get (without clearing):
2 + 1 0 = 12
5 = 22
0 = 32Then you haven't used very many calculators: https://tedmuller.us/Math/Calculator-1'Introduction.htm
Sometimes you just have to put your foot down and just say "No, that is not how you use this tool".
> Shit. I was just about to launch into an explanation of our code review procedures. Every week we sit around a table and carefully and dispassionately analyse and constructively criticise each others code. And it works. We sit there and listen and take it all in. It works really well and team morale is excellent. One day we're even planning to do one when we're sober.
You can even go fancy with floating point if you want (Probably elims the $0.30 MCUs). Tiny, cheap, and you can model it using appropriately expressive data structures (like rust enums) that handle the edge cases at the CPU level.
I don't mean to dismiss your comment; it's important. I think this article is skirting a gray area of which constraints are applied. Then the conclusion is altered. Is it saying making a 4-function calculator is complicated!, or is it saying making a 4-function calculator is complicated if you add a number of specific restrictions and requirements (No modern CPU code, exact behavior replication to all combinations of user input etc). The latter is less interesting.
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.
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 progressive enhancement would reveal the most logical or economical UI.
So 7 + 1 * 5 ÷ 0 CE 4 = 10 And 7 + 1 * 5 ÷ 0 C 4 = 4
Also supports saving a result into a variable for later reference, and x "as proportion of" y, which is just an alias for division.
into and from may be easier for the average joe to read though
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.
Can't remember how physical calculators deal with them, but software calculators deal with them differently.
To the point that iOS calc and MacOS calc are different. And variations of Windows calc (regular/scientific/engineering) are different
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.
There's no precedence. Everything is left or right. Every button is a prefix command: OP ARG or else just OP.
For instance 3 + 4 x 3 - 1 x 9 - can be evaluated in a particular Lisp dialect as
(lflow 3 (+ 4) (* 3) (- 1) (* 9) -)
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.
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.
When an ARG is entered not preceded by an OP, it replaces the accumulator.
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.
Later when I designed some expression evaluators I've started to appreciate the language design (and hacks) required to make "100 - 5%" work "as expected" (that is, return 95). It's a pretty unusual grammar, and it is neat that it was implemented on something with only few dozens bytes of RAM.
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 even had a duplicate of it where I unplugged the broken solar panel and put 2x AA batteries on the back to power it. So the solar panel definitely worked
how do you diff between div/mul if not by double tap?
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:
4 x÷ 2 += gives the answer 8. 4 x÷ 2 -= gives the answer 2.
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
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.
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.
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.
Please, I would much prefer device for RPN calculation, that follows consistent logic, rather than silly imposed rules.
4+7*3 etc.
or 4 7 + 3 * =
Where the latter is much closer to what we do in our heads and conceptually think about it.
One thing she can operate is her HP-12C calculator. At the time of it's initial release, someone taught her how to use it, knowing that the RPN interface would be much easier to teach her than infix notation that was equally popular at the time. She never figured out infix notation, at least for more than single operations.
Pretty much everything uses infix notation now a days, so that's what everyone learns first, making RPN an additional skill that usually gets passed by.
It's interesting to learn that there was a time when a calculators interface was a toss-up, and some people learned RPN because it was the easiest to learn, as opposed to it now being an additional skill that would conflict with earlier experience.
Someone born in 1930s would have learned infix arithmetic in school just like somebody born in the 2010s.
Cannot work a remote, but can use RPN on an HP calculator? That sounds AI generated.
It's stateful and modal interfaces that are an extra step she never figured out, and some TV remotes require different modes for different functions, especially for different equipment. CEC has solved this on modern TVs, but it used to be common to have control the VCR/DVD player by selecting a mode, then control the TV by selecting another mode, and even without the other equipment, she could accidentally get the remote in the wrong mode.
She never got the hang of the states that are possible in a calculator with an interface using infix notation, so instead of using parentheses or order of operation, if she didn't have access to an RPN calculator, she'd write down results and enter them back as needed, to only have one operation in progress at a time, in the calculator.
They are prefix operations that take an implicit accumulator as an argument, resulting in something that superficially mimics a purely left-associative form of infix, with all operators having the same precedence.
For instance when we punch in 2 + 3 x 4 / 10 x 3 = = =, it means:
2 # prepare operand 2 in display
+ # move 2 into accumulator, prepare for addition
3 # prepare operand 3 in display
x # complete addition of acc 2 and operand 3, move 5 into acc and display
4 # prepare operand 4 in display
/ # complete multiplication of acc 5 and operand 4, move 20 into acc and dispay
10 # prepare operand 10 in display
x # complete division, moving 2 into acc and display
3 # prepare operand 3 in display
= # complete multiplication of acc 2 and 3, moving 6 into acc and display
= # complete multiplication of acc 6 and 3, moving 18 into acc and display
= # complete multiplication of acc 18 and 3, moving 54 into acc and display
$ echo 2 | plus 3 | times 4 | divide 10 | ...
"Start with 3; add 4; mutiply by 2; divide by 7; ....; ... write down the result."
I'm deeply skeptical that someone who had been through these drills would have trouble with a dollar store calculator.
My MIL can operate her phone and iPad but is constantly confused by the Roku and has to ask for help.
"Reverse Polish notation", I think, for people like me who aren't familiar with the acronym.
Besides, infix-style calculators also seem to use a stack to handle operator precedence — if you squint a bit at the manual, you can usually see the shunting-yard algorithm at work behind the curtains.
Actually, some really early HP:s (only desktops, though, like the 9100) used a three-level “stack”, which I put in quotes, because it relied on the user to shift the registers up and down as needed. But they cheated a bit and displayed all three registers, so that the user could see what was where.
True, but simple calculators, even ones a bit more advanced than the one in the article (e.g. with a sqrt and/or % key) don't handle operator precedence. I'm not sure it's even correct to call them infix calculators, for that reason. They simply work sequentially; no stack needed.