[HN Gopher] UI is hell: four-function calculators
___________________________________________________________________
UI is hell: four-function calculators
Author : surprisetalk
Score : 209 points
Date : 2025-01-24 03:46 UTC (19 hours ago)
(HTM) web link (lcamtuf.substack.com)
(TXT) w3m dump (lcamtuf.substack.com)
| andrewfromx wrote:
| "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"
| labster wrote:
| But the calculators last much longer than smart fridges because
| they don't rely on central server existing to continue
| operating.
| bathtub365 wrote:
| They fixed that by making solar calculators that rely on the
| continued existence of our temporary sun.
| TeMPOraL wrote:
| 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?
| 01HNNWZ0MV43FF wrote:
| 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
| persnickety wrote:
| 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.
| saagarjha wrote:
| 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.
| aitchnyu wrote:
| The screen would go faint and slow when the power sources
| werent running at peak.
| Ekaros wrote:
| 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.
| bawolff wrote:
| I always found percent key behaviour to be such a bizarre choice.
| theamk wrote:
| 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.
| quesomaster9000 wrote:
| 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.
| ziml77 wrote:
| 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.
| airstrike wrote:
| 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
| ziddoap wrote:
| > _RPN_
|
| "Reverse Polish notation", I think, for people like me who
| aren't familiar with the acronym.
| nejsjsjsbsb wrote:
| You thank!
| layer8 wrote:
| !ejukeizD
| mattkrause wrote:
| It really should stand for "Notation: Polish (Reversed)."
| x3n0ph3n3 wrote:
| 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?
| Pinus wrote:
| 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.
| roelschroeven wrote:
| > 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.
| kazinator wrote:
| Compared to what? RPN allows for complex, nested expressions
| for which infix requires nested parentheses. Nesting requires
| a stack, the same way.
| dlcarrier wrote:
| 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.
| kazinator wrote:
| 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.
| dlcarrier wrote:
| 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.
| kazinator wrote:
| 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.
| SoftTalker wrote:
| 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.
| Jaxan wrote:
| You also don't need pedmas if you just use parentheses to
| disambiguate your expressions. That's what mathematicians would
| do.
| jwagenet wrote:
| 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.
| gnatolf wrote:
| 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...
| mazambazz wrote:
| 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".
| jansan wrote:
| 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/
| mrbombastic wrote:
| 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
| userbinator wrote:
| Those "edge cases" actually aren't; they're simply "emergent
| behaviour" of how the state machine in the ASIC works.
| the__alchemist wrote:
| 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.
| userbinator wrote:
| 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): 2 + 1 0 = 12
| 5 = 22 0 = 32
| saurik wrote:
| Apple's recent iOS Calculator update broke this entirely and
| now = multiple times does nothing :/.
| oogetyboogety wrote:
| those fuckers. If windows wants to add this as a success
| where Mac has failed, it still works in their calculator app.
| actionfromafar wrote:
| Windows also innovated from TTC to TTCC! (Time to Candy
| Crush, instead of Time to Crate.)
| saagarjha wrote:
| This is fixed in the latest beta, which is probably going to
| ship next week or thereabouts.
| wruza wrote:
| 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.
| anarticle wrote:
| 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!
| serviceberry wrote:
| > 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
| openrisk wrote:
| > Let's start with the basics: the simplest calculator has ten
| digit keys, a decimal dot, four arithmetic operators (+, -, x,
| /), 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.
| contravariant wrote:
| 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(
| kqr wrote:
| 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.)
| persnickety wrote:
| 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.
| tgv wrote:
| 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.
| _moof wrote:
| 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.
| persnickety wrote:
| 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.
| enriquto wrote:
| > 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).
| ropejumper wrote:
| They meant that the implementation of a four-function
| calculator only needs a few fixed variables rather than a
| stack.
| PeterStuer wrote:
| 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.
| koblas wrote:
| 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.
| PeterStuer wrote:
| I did do that! But data entry was so laborious that by the
| time you entered the formulas you basically knew them by
| hard.
| nottorp wrote:
| 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.
| 7thaccount wrote:
| 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.
| ghaff wrote:
| 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.)
| 7thaccount wrote:
| 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).
| DarkSucker wrote:
| 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.
| genewitch wrote:
| 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.
| layer8 wrote:
| Yes, RPN is easier to implement, and for the same reason also
| easier to reason about as a user,
| 7thaccount wrote:
| 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.
| bruce343434 wrote:
| > 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!
| roelschroeven wrote:
| 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.
| 7thaccount wrote:
| 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.
| kstrauser wrote:
| 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.
| 7thaccount wrote:
| 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.
| wtallis wrote:
| The whole 48/49/50 series covering 1990-2015 has that
| equation writer functionality, or in other words: every
| RPN graphing calculator.
| billmcneale wrote:
| 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.
| kccqzy wrote:
| Why would you need to enter the deepest expression first?
| 7thaccount wrote:
| 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.
| billmcneale wrote:
| 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 / + +
| Kim_Bruning wrote:
| Do you also use dc? (can be used on terminal / termux)
|
| https://linux.die.net/man/1/dc
| kqr wrote:
| 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.
| taeric wrote:
| 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?
| alexjm wrote:
| 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.
| kibwen wrote:
| Agreed, my spicy take is operator precedence was a mistake that
| we regrettably inherited from mathematical notation.
| Parentheses for grouping are fine, at least.
| troupo wrote:
| 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
| kazinator wrote:
| 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.
| kccqzy wrote:
| Doesn't the Android calculator use constructive reals?
| https://cacm.acm.org/practice/small-data-computing/
| jamesfisher wrote:
| As usual, this is completely unreadable on mobile due to
| Substack's hatred for zoom
| gushogg-blake wrote:
| 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.
| beeflet wrote:
| Maybe you could do the same thing by having a negation and
| reciprocal button?
| gushogg-blake wrote:
| 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.
| beeflet wrote:
| 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
| layer8 wrote:
| RPN calculators have that (swap button).
| layer8 wrote:
| 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.
| bowsamic wrote:
| 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
| rbanffy wrote:
| 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.
| gf000 wrote:
| 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".
| the-grump wrote:
| 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.
| ghaff wrote:
| I've been RPN for so long that I pretty much need an RPN
| calculator app even for relatively simple stuff.
| kstrauser wrote:
| 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.
| ghaff wrote:
| 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.
| airstrike wrote:
| 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
| ChrisMarshallNY wrote:
| I've been using PCalc, since last century (it does have an
| RPN mode).
|
| https://pcalc.com/
| ATMLOTTOBEER wrote:
| You're right it was terrible for a while. I'm glad they fixed
| it.
| Suppafly wrote:
| >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?
| SoftTalker wrote:
| 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.
| Someone wrote:
| 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
| (3 + 4) * 7 =
|
| to get _49_.
|
| For an example see the TI-25 at
| http://www.datamath.org/Sci/Slimline/TI-25.htm
| SoftTalker wrote:
| Well I was responding to a post about "really cheap
| calculators" not non-cheap ones or iOS ones.
| kevin_thibedeau wrote:
| 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.
| Retric wrote:
| 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.
| pasquinelli wrote:
| > 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.
| Retric wrote:
| > 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.
| dhosek wrote:
| When I used to teach math, the difference in how calculators
| handled precedence was always a problem. I would tell students
| to enter 1+2x3 into their calculators and if they got 9,1 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_.
| kweingar wrote:
| 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.
| tmjdev wrote:
| 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.
| khaki54 wrote:
| New technical interview question just dropped
| phreack wrote:
| 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.
| genewitch wrote:
| 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
| iamnotsure wrote:
| Does your calculator use bigints for subtraction? why? why not?
| ForHackernews wrote:
| 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.
| 2-3-7-43-1807 wrote:
| > 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?
| billmcneale wrote:
| 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.
| kazinator wrote:
| 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.
| carb wrote:
| 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.
| thih9 wrote:
| 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...
| humptybumpty wrote:
| But what about:
|
| 4 -= 1 +=
|
| 4 -= 1 -=
|
| I'm guessing 3 and 3?
| thih9 wrote:
| 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
| manchmalscott wrote:
| 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.
| brundolf wrote:
| 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
___________________________________________________________________
(page generated 2025-01-24 23:01 UTC)