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.
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.
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.
> 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’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.
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.
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.
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.
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.
> 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]).
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.
> 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.
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
Readit News
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?
https://pcalc.com/
(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.
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 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.
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.
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.
https://linux.die.net/man/1/dc
----
> 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?
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):
Then 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".
[1] https://www.theregister.com/2006/10/13/code_outrage/
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