Just putting it out here - before the recentish redesign of ios's default calculator, it had a widely 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.
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".
When I used to teach math, the difference in how calculators handled precedence was always a problem. I would tell students to enter 1+2×3 into their calculators and if they got 9,¹ they should throw away the calculator and buy one that worked properly. Not respecting the precedence rules is bad design.
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.
Except that if you’re a high school student who is using a calculator for stuff most if not all of the readers on this site would do in your head, having a calculator that ignores precedence just makes things that much harder.
A high school student should already know the difference between a dumb calculator that can only show a single number and a smart calculator that lets you to write a full line while using () before pressing =, having used both already by middle school.
These "four-function" calculators only display the last number. It would be widely unexpected if doing x3 when all I see is a 2 would sometimes give 6 or some other value (e.g. the student next to me just passed a calculator with a value displayed, so I don't know if it had any previous instructions and no way to find out)
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.
>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.
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?
I would have assumed that cheap (i.e. 4-function, LCD) calculators today have the same internals as cheap calculators from the 1980s. Why reinvent what works, when you can just keep selling it.
Why would you assume iOS, not being the cheap option for a smartphone, would choose to emulate a cheap calculator?
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
The point is, precedence following expression evaluation calculators starting from the 80s have always shown you the expression. No expression and no parentheses buttons (accumulator stack) implies a simple accumulator based design.
> Why would you assume iOS, not being the cheap option for a smartphone, would choose to emulate a cheap calculator?
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.
I didn’t start using RPN until many years after graduating college, but took to it like a fish to water. I never again have to guess what the calculator might be doing behind the scenes. It’s doing exactly what I told it, no more or less, in precisely the order I told it.
When I started college, HPs were still really expensive so I got a TI which still wasn’t cheap. But calculator prices were plummeting like a stone and got a (relative) deal on a HP-55 a year or two later.
this is me too. I literally can't use a regular calculator anymore and I'm not even doing fancy math. my brain was just permanently rewired by the HP-12c
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?
(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.)
I own several RPN calculators (they are very cool), but still find modern TI or Casio calculators to be superior now when I'm not using a spreadsheet or something like Mathematica.
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.
I have an HP 50g that makes it easy to flip between RPN and textbook-style graphical equations where you can arrow around and tweak any value. You can have both approaches in the same place.
Agreed, but the 50g is ancient and is the only calculator to my knowledge that has that capability.
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.
> things [] are just easier to reason about when you can see it matches what is on the paper in front of you.
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.
There are disadvantages to RPN as well. I read a book on the Forth programming language (also uses RPN) and some calculations that are algebraically simple require pretty bizarre stack shuffling with RPN stacks. I wish I had the source example. It was something pretty standard in a highschool algebra book like the midpoint formula or something like that. The reverse might be true as well in some situations, but I can't recall any examples outside of RPN's historical advantage against old TI calcs in the 80s. Maybe a forth or RPN enthusiast could help.
I’ve been thinking that an RPN calculator app could easily display the full natural expression while you enter it in RPN. And let you modify it afterwards.
I used to be in love with RPN and owned multiple HP calculators (HP-41, HP-15) but RPN is cheating by offloading effort on the user.
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.
I think they mean that for a complicated expression you have to spend more brain power figuring out how to input things with RPN. It is a little more common sense with infix.
Agreed, my spicy take is operator precedence was a mistake that we regrettably inherited from mathematical notation. Parentheses for grouping are fine, at least.
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.
That link made my day! Thank you. From what I read, their builds perform better than the originals, and they even make landscape versions. Woo hoo! RPN rules in my book. I picked up an HP 32 before they were gone forever, but I've been afraid to use it. It's great to know about SwissMicros; they'll get my business soon.
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.
I've been really tempted as my 41CV doesn't work any longer but I do real calculating so little that it would just be a nostalgia trip. (And I have a couple of the horizontal format HP calcs that still work for any of the calculator stuff I do sometimes do outside of an app.)
Yeah, for me it's mainly a hobbyist thing without much value at this point (probably better uses for my money). I'd love to have something like the 15c with a much bigger screen that does APL with physical buttons. Now that would be cool. I effectively have that on a tablet though (minus the dedicated system with physical buttons).
A decent way to cram for an exam you don't care much about is to hand copy the course material too. You'll most likely end up retaining enough to pass.
RPN is definitely easier to implement. I helped someone do that as a student project and while it was minimally complex, there were no edge cases with the operators.
You pay for that by having a stack rather than a small fixed number of variables.
> 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).
My HP RPN calculator only has four positions available in its stack, which I imagine makes the implementation a bit simpler than a stack of arbitrary size.
The typical 4-function calculator doesn't even allow multiple subtrees of computation, so I think it works out to having something like 2 entries on the stack.
Yes, but mainly in scripts and oneliners (never learned the Bash arithmetic substitution thing). For interactive use I often have a shorter time-to-arrival to either Emacs or RealCalc.
I have a kitchen slide that I use for ratios in recipes. It's an old plastic one from Think Geek.
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:
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: https://news.ycombinator.com/item?id=9456444
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):
iOS calc sometimes registers a press but not a release(?) and a key gets stuck in "pressed" state and doesn't count as an input. Many years issue which renders it completely unusable, unless you're careful with your tapping. A new level of skeuomorphism, I guess, non-physical buttons that get stuck.
The AC to backspace change really screwed me up and I'm back on a third party calculator. It's a speed bump that feels like hitting a brick wall every time!
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...
Traditionally this would be solved by inserting a comment into the code that insults the user (for example the classic "The user is a wanker" comment [1]).
> 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.
I think there is a lesson here. Don’t let edge cases define your complexity whenever possible. Check if it is in fits your valid expressions and if it doesn’t do nothing, otherwise you get a mess of if x then y
You don't need an ASIC in the way the article's challenge described the lunch problem. Do it with an MCU. The article goes into how the author did it at the register level, but that is not how a modern audience would do it. If you're doing registers, it's probably for your MCU's CORDIC peripheral etc for trig!
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.
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.
> 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.
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.
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: https://fluent-calc.vercel.app/
Also supports saving a result into a variable for later reference, and x "as proportion of" y, which is just an alias for division.
Yes, I use those all the time for exactly that purpose. In many cases you don't even need to worry in which order to enter the operands when calculating a difference or ratio, just press negate or reciprocal if the result doesn't look right.
This is why every calculator ever should have a RPN mode. Postfix notation removes all of that parsing ambiguity.
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.
Simple calculators are actually a bit like functional pipes.
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) -)
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.
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.
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.
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.
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.
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.
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"
Some didn't. In today's world it is actually amazing how little power those things used. Both for that type of LCD screen and doing some calculations. Just compare it to almost anything else we use daily.
There were calculators in the '90s where the display would go faint when you covered the tiny solar panel. Perhaps the battery was already drained. Quite common I would say.
There's counterfeit ones yes, but somewhere I have a real solar calculator.
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
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.
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
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.
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.
My grandma, born in the 30's, isn't any good at computers or technology in general, and has trouble operating even the simplest TV remotes and cordless phones.
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.
It's nowadays that everyone learns infix calculator input methods as children. In the 40's they sure weren't learning any calculator user interfaces.
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.
Other than advanced, graphing calculators that take full blown formulas as input, ordinary pocket calculators are not infix.
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
It's really
$ echo 2 | plus 3 | times 4 | divide 10 | ...
I remember doing math drills like this in elementary school. The teacher startws with a number and then calls out operations:
"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.
Working RPN requires a substantial increment in intellectual capacity compared to applying a sequence of elementary operations to an accumulator. An operand consumed by a given RPN operation can be quite distant from it in the syntax, such that it's not obvious which one. A valid RPN expression could consist of an initial sequence of N operands, where N is limited only by stack depth, followed by a sequence of N-1 operators to decimate the operands.
I don't see how PEMDAS is relevant for a 4 function calculator. The implicit equals when you press an operator means that they always work sequentially rather than jumping around.
As far as I can tell, PEMDAS has nothing to do with the calculator itself and is just the rules we’ve arrived at for how to read and write equations in a consistent way.
RPN requires implementing a stack on silicon, which adds even more complexity and uncertainty. How deep can the stack go? What happens to your calculation when you exceed its capacity?
Classic HP calculators used a fixed stack of four registers. In practice, you can do quite complicated things before you blow that up. Especially if you understand how the mechanism works, and plan ahead a bit.
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.
> Besides, infix-style calculators also seem to use a stack to handle operator precedence
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.
Just putting it out here - before the recentish redesign of ios's default calculator, it had a widely 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.
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".
When I used to teach math, the difference in how calculators handled precedence was always a problem. I would tell students to enter 1+2×3 into their calculators and if they got 9,¹ they should throw away the calculator and buy one that worked properly. Not respecting the precedence rules is bad design.
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.
Not respecting precedence is ok, as long as the user is aware of it.
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.
Except that if you’re a high school student who is using a calculator for stuff most if not all of the readers on this site would do in your head, having a calculator that ignores precedence just makes things that much harder.
A high school student should already know the difference between a dumb calculator that can only show a single number and a smart calculator that lets you to write a full line while using () before pressing =, having used both already by middle school.
These "four-function" calculators only display the last number. It would be widely unexpected if doing x3 when all I see is a 2 would sometimes give 6 or some other value (e.g. the student next to me just passed a calculator with a value displayed, so I don't know if it had any previous instructions and no way to find out)
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.
just tested this. in "standard" mode you get 7, switch to "scientific" you get 9.
You’re right it was terrible for a while. I’m glad they fixed it.
>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.
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?
I would have assumed that cheap (i.e. 4-function, LCD) calculators today have the same internals as cheap calculators from the 1980s. Why reinvent what works, when you can just keep selling it.
Why would you assume iOS, not being the cheap option for a smartphone, would choose to emulate a cheap calculator?
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
to get 49.For an example see the TI-25 at http://www.datamath.org/Sci/Slimline/TI-25.htm
The point is, precedence following expression evaluation calculators starting from the 80s have always shown you the expression. No expression and no parentheses buttons (accumulator stack) implies a simple accumulator based design.
The app did have parentheses buttons, depending on rotation you’d get simple or scientific UI.
Rotation changing how the calendar handled order of operations seems even less intuitive to me.
> Why would you assume iOS, not being the cheap option for a smartphone, would choose to emulate a cheap calculator?
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.
> ui for the ios calculator app is the same as the ui of a cheap calculator.
Rotate it and the app was a basic scientific calculator.
Well I was responding to a post about "really cheap calculators" not non-cheap ones or iOS ones.
One of first things I do when I set up a new iThing is to delete the calculator app and install a third-party calculator.
I've been RPN for so long that I pretty much need an RPN calculator app even for relatively simple stuff.
I didn’t start using RPN until many years after graduating college, but took to it like a fish to water. I never again have to guess what the calculator might be doing behind the scenes. It’s doing exactly what I told it, no more or less, in precisely the order I told it.
When I started college, HPs were still really expensive so I got a TI which still wasn’t cheap. But calculator prices were plummeting like a stone and got a (relative) deal on a HP-55 a year or two later.
this is me too. I literally can't use a regular calculator anymore and I'm not even doing fancy math. my brain was just permanently rewired by the HP-12c
I’ve been using PCalc, since last century (it does have an RPN mode).
https://pcalc.com/
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?
(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.)
I own several RPN calculators (they are very cool), but still find modern TI or Casio calculators to be superior now when I'm not using a spreadsheet or something like Mathematica.
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.
I have an HP 50g that makes it easy to flip between RPN and textbook-style graphical equations where you can arrow around and tweak any value. You can have both approaches in the same place.
Agreed, but the 50g is ancient and is the only calculator to my knowledge that has that capability.
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.
The whole 48/49/50 series covering 1990–2015 has that equation writer functionality, or in other words: every RPN graphing calculator.
Good point.
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.
> things [] are just easier to reason about when you can see it matches what is on the paper in front of you.
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!
Is infix notation even that bad?
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.
There are disadvantages to RPN as well. I read a book on the Forth programming language (also uses RPN) and some calculations that are algebraically simple require pretty bizarre stack shuffling with RPN stacks. I wish I had the source example. It was something pretty standard in a highschool algebra book like the midpoint formula or something like that. The reverse might be true as well in some situations, but I can't recall any examples outside of RPN's historical advantage against old TI calcs in the 80s. Maybe a forth or RPN enthusiast could help.
I’ve been thinking that an RPN calculator app could easily display the full natural expression while you enter it in RPN. And let you modify it afterwards.
I haven’t found such an interface yet.
I used to be in love with RPN and owned multiple HP calculators (HP-41, HP-15) but RPN is cheating by offloading effort on the user.
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.
Why would you need to enter the deepest expression first?
I think they mean that for a complicated expression you have to spend more brain power figuring out how to input things with RPN. It is a little more common sense with infix.
Yes, exactly.
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 / + +
Agreed, my spicy take is operator precedence was a mistake that we regrettably inherited from mathematical notation. Parentheses for grouping are fine, at least.
In my youth my treasure was a HP41cv. I always found RPN far more logical, conceptually cleaner and as a result far simpler to use.
If you want a recreation:
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.
That link made my day! Thank you. From what I read, their builds perform better than the originals, and they even make landscape versions. Woo hoo! RPN rules in my book. I picked up an HP 32 before they were gone forever, but I've been afraid to use it. It's great to know about SwissMicros; they'll get my business soon.
Not a problem.
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.
I've been really tempted as my 41CV doesn't work any longer but I do real calculating so little that it would just be a nostalgia trip. (And I have a couple of the horizontal format HP calcs that still work for any of the calculator stuff I do sometimes do outside of an app.)
Yeah, for me it's mainly a hobbyist thing without much value at this point (probably better uses for my money). I'd love to have something like the 15c with a much bigger screen that does APL with physical buttons. Now that would be cool. I effectively have that on a tablet though (minus the dedicated system with physical buttons).
OK I always see this sentiment.
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.
Plus, for owners of the HP41, if you had an essay question in your chemistry test you could type in cliff notes... Naw, I never did that.
I did do that! But data entry was so laborious that by the time you entered the formulas you basically knew them by hard.
A decent way to cram for an exam you don't care much about is to hand copy the course material too. You'll most likely end up retaining enough to pass.
Yes, RPN is easier to implement, and for the same reason also easier to reason about as a user,
RPN is definitely easier to implement. I helped someone do that as a student project and while it was minimally complex, there were no edge cases with the operators.
You pay for that by having a stack rather than a small fixed number of variables.
> 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).
They meant that the implementation of a four-function calculator only needs a few fixed variables rather than a stack.
My HP RPN calculator only has four positions available in its stack, which I imagine makes the implementation a bit simpler than a stack of arbitrary size.
The typical 4-function calculator doesn't even allow multiple subtrees of computation, so I think it works out to having something like 2 entries on the stack.
Classical 4-func calcs are easier, I think. They don't even need a stack, just a place to store the previous value and the current input.
Do you also use dc? (can be used on terminal / termux)
https://linux.die.net/man/1/dc
Yes, but mainly in scripts and oneliners (never learned the Bash arithmetic substitution thing). For interactive use I often have a shorter time-to-arrival to either Emacs or RealCalc.
I'm super intrigued on the slide rule idea! Where did you get one and what sort of stuff do you typically do with it?
I have a kitchen slide that I use for ratios in recipes. It's an old plastic one from Think Geek.
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.
If anyone else was curious about the final image and the `x÷` button: http://www.vintagecalculators.com/html/sharp_el-8.html
----
> 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.
Thank you! This looks surprisingly intuitive, perhaps even comfortable, especially when muscle memory kicks in.
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...
But what about:
4 -= 1 +=
4 -= 1 -=
I’m guessing 3 and 3?
My guess is different; these calculators did support negative numbers; I’d say:
4 –= 1 += gives: -3
4 –= 1 –= gives: -5
Manual for a similar model: https://www.oldcalculatormuseum.com/m-sharpqt8d.pdf
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: https://news.ycombinator.com/item?id=9456444
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):
Apple's recent iOS Calculator update broke this entirely and now = multiple times does nothing :/.
iOS calc sometimes registers a press but not a release(?) and a key gets stuck in "pressed" state and doesn't count as an input. Many years issue which renders it completely unusable, unless you're careful with your tapping. A new level of skeuomorphism, I guess, non-physical buttons that get stuck.
This is fixed in the latest beta, which is probably going to ship next week or thereabouts.
The AC to backspace change really screwed me up and I'm back on a third party calculator. It's a speed bump that feels like hitting a brick wall every time!
those fuckers. If windows wants to add this as a success where Mac has failed, it still works in their calculator app.
Windows also innovated from TTC to TTCC! (Time to Candy Crush, instead of Time to Crate.)
> I haven't used any 4-function calculator that behaves like this; instead, I get (without clearing):
Then you haven't used very many calculators: https://tedmuller.us/Math/Calculator-1'Introduction.htm
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...
I, too, have been caught in the trap of trying to accommodate all possible user flows.
Sometimes you just have to put your foot down and just say "No, that is not how you use this tool".
Traditionally this would be solved by inserting a comment into the code that insults the user (for example the classic "The user is a wanker" comment [1]).
[1] https://www.theregister.com/2006/10/13/code_outrage/
The site linked in comments is gold.
> 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.
I think there is a lesson here. Don’t let edge cases define your complexity whenever possible. Check if it is in fits your valid expressions and if it doesn’t do nothing, otherwise you get a mess of if x then y
Those "edge cases" actually aren't; they're simply "emergent behaviour" of how the state machine in the ASIC works.
You don't need an ASIC in the way the article's challenge described the lunch problem. Do it with an MCU. The article goes into how the author did it at the register level, but that is not how a modern audience would do it. If you're doing registers, it's probably for your MCU's CORDIC peripheral etc for trig!
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.
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.
CE is clear entry to my brain, regardless of the actual etymology.
So 7 + 1 * 5 ÷ 0 CE 4 = 10 And 7 + 1 * 5 ÷ 0 C 4 = 4
> 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.
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.
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: https://fluent-calc.vercel.app/
Also supports saving a result into a variable for later reference, and x "as proportion of" y, which is just an alias for division.
Maybe you could do the same thing by having a negation and reciprocal button?
Yes, I use those all the time for exactly that purpose. In many cases you don't even need to worry in which order to enter the operands when calculating a difference or ratio, just press negate or reciprocal if the result doesn't look right.
Yeah, having dedicated operators for going the other way just fit my mental model better for the types of tasks I had in mind for it.
Hmm, well then maybe it would be simpler to have a single button that swaps the input and the accumulator?
into and from may be easier for the average joe to read though
RPN calculators have that (swap button).
This is why every calculator ever should have a RPN mode. Postfix notation removes all of that parsing ambiguity.
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.
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
Simple calculators are actually a bit like functional pipes.
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
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.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.
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.
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.
As usual, this is completely unreadable on mobile due to Substack's hatred for zoom
I still wish to find the idiot who thought the reasonable thing to do when someone types 2 followed by SQRT is to return 2sqrt(
I always found percent key behaviour to be such a bizarre choice.
When I was a student, I thought the same.
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.
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.
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.
The generic, basic LCD calculator is missing solar cells. Should be sine qua non these days for a simple device like this.
"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"
But the calculators last much longer than smart fridges because they don’t rely on central server existing to continue operating.
They fixed that by making solar calculators that rely on the continued existence of our temporary sun.
I thought those solar panels are fake decorative elements only; the calculator still needs a battery to work and stops working when it runs out?
Some didn't. In today's world it is actually amazing how little power those things used. Both for that type of LCD screen and doing some calculations. Just compare it to almost anything else we use daily.
There were calculators in the '90s where the display would go faint when you covered the tiny solar panel. Perhaps the battery was already drained. Quite common I would say.
I had one in the 2010s when I was going through grade school. Casio fx-260 solar; it would die in seconds if you covered the panel.
The screen would go faint and slow when the power sources werent running at peak.
There's counterfeit ones yes, but somewhere I have a real solar calculator.
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
> Yes, there are buttons. No, it doesn’t support double-tap or long press.
how do you diff between div/mul if not by double tap?
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.
nice concept but a very bad choice to illustrate good UI. there is enough space to add a few more buttons with dedicated functions.
In 2025, sure. Back when that calculator came out, this kind of saving was probably worth it.
eh why? believe it or not but they had even keyboards back then with many dozens of keys.
New technical interview question just dropped
Does your calculator use bigints for subtraction? why? why not?
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
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.
Doesn't the Android calculator use constructive reals? https://cacm.acm.org/practice/small-data-computing/
TL;DR PEDMAS is bullshit
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.
My grandma, born in the 30's, isn't any good at computers or technology in general, and has trouble operating even the simplest TV remotes and cordless phones.
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.
Infix isn't "nowadays". It's been with us for hundreds of years. Moreover infix constructs occur in natural languages. You know "apples and oranges".
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 nowadays that everyone learns infix calculator input methods as children. In the 40's they sure weren't learning any calculator user interfaces.
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.
Other than advanced, graphing calculators that take full blown formulas as input, ordinary pocket calculators are not infix.
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:
It's really I remember doing math drills like this in elementary school. The teacher startws with a number and then calls out operations:"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.
Yeah, that's why I stick with RPN calculators.
Working RPN requires a substantial increment in intellectual capacity compared to applying a sequence of elementary operations to an accumulator. An operand consumed by a given RPN operation can be quite distant from it in the syntax, such that it's not obvious which one. A valid RPN expression could consist of an initial sequence of N operands, where N is limited only by stack depth, followed by a sequence of N-1 operators to decimate the operands.
TVs and their remotes mostly have fantastically terrible UX.
My MIL can operate her phone and iPad but is constantly confused by the Roku and has to ask for help.
>RPN
"Reverse Polish notation", I think, for people like me who aren't familiar with the acronym.
You thank!
!ęjukęizD
It really should stand for “Notation: Polish (Reversed).”
I don't see how PEMDAS is relevant for a 4 function calculator. The implicit equals when you press an operator means that they always work sequentially rather than jumping around.
I think they're saying it's bullshit because if we used (the superior) RPN across the board, we wouldn't need PEMDAS at all
As far as I can tell, PEMDAS has nothing to do with the calculator itself and is just the rules we’ve arrived at for how to read and write equations in a consistent way.
RPN requires implementing a stack on silicon, which adds even more complexity and uncertainty. How deep can the stack go? What happens to your calculation when you exceed its capacity?
Classic HP calculators used a fixed stack of four registers. In practice, you can do quite complicated things before you blow that up. Especially if you understand how the mechanism works, and plan ahead a bit.
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.
> Besides, infix-style calculators also seem to use a stack to handle operator precedence
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.
Compared to what? RPN allows for complex, nested expressions for which infix requires nested parentheses. Nesting requires a stack, the same way.
You also don’t need pedmas if you just use parentheses to disambiguate your expressions. That’s what mathematicians would do.