How does the calculator percent key work? (2008)
blogs.msdn.com
blogs.msdn.com
I never understood how these cheap calculators worked. I'm glad most serious desktop calculator apps, like the OS X one, have a RPN mode. As a high schooler, my dad forced me to switch to RPN calculators when we began doing very lengthy calculations.
People thought I was a freak. But in retrospect, it was an awesome decision. With a stack, things are much simpler. You don't need those clumsy memory registers or parentheses, and all operators have a very simple semantics.
As a bonus point, an innocent looking HP15C implements or can implement quite advanced numerical methods. It was a secret retro weapon from the 80s when all they allowed were non-graphical calculators.
M-x calc in Emacs is a very full-featured RPN calculator.
On Android, I use Droid48, a great HP48 emulator: https://play.google.com/store/apps/details?id=org.ab.x48 ; I also have RealCalc (https://play.google.com/store/apps/details?id=uk.co.nickfine...) installed, which I figured I'd use more due to the bigger buttons by default, but I still reach for Droid48 most often.
I use dc and bc on the command line. Some people have chided me saying the command line calculators aren't always accurate and are buggy, but I haven't seen any problems.
Interesting tidbit, it seems that dc is the oldest language on Unix; it was ported before even an assembler was. (https://en.wikipedia.org/wiki/Dc_%28computer_program%29#Hist...)
https://news.ycombinator.com/item?id=5054618
a couple of replies to my comment there about exponents. specifically.
"bc is a pretty misleading calculator, without specifying rounding it thinks 2^(40/1.5) is 67108864.
It's not even close.
If you trust your finances to that, you could get in trouble. "
Sadly, since dc doesn't have a math library, it looks like you can't use the "e" function workaround unless you implement it yourself.
I'm pretty sure you can access every feature the calculator has from its stack, which means they're all available for use in programs; it also comes with a nice equation library full of physics equations with helpful diagrams and information about what various variables are.
Quite amazing for the time, and still very useful. It's frugal with batteries, too.
They are usually based on the two-register model, or at least the very very simplest ones: one accumulator, R, holds the "result"; another accumulator, I, holds the input. The button CE clears I to 0, and C clears R to 0. The display always shows the contents of the most recently modified accumulator. An "operation" register, O, contains the most recently pressed operation button and is initially the null operation. Inputting digits/decimal points modifies I.
Whenever +, -, , / are entered, it performs R = R O I and then sets O to the new most recent operation. When '=' is pressed, R = R O I without changing the most recent operation. This is why sequences like 1+2+54= gives 32, and then '=' again will multiply 32 by 4, etc.
This type of calculator is easy to identify because it has no notion of operator precedence and always evaluates in the sequence it's given, and furthermore doesn't actually require an '=' key - observe that if e.g. you input 2+2-, 2+2+, 2+2/, or 2+2*, the display already shows 4 because entering the last op has caused the previous op + to be evaluated giving R += I, and the display shows the new value of R.
Those with a "memory" function add another accumulator, M. Then the operation MC is M=0, M+ performs M+=R or M+=I (depending on the currently displayed register), M- is M-=R or M-=I, and MR is I=M.
When the user enters a value, an operator, a second value, and then the percent key, the first two values are multiplied and the product divided by 100, and that result replaces the second value in the ongoing computation.
If you watch the display as you go through this exercise, you will even see the number 3.6 appear in the display once you press the % key. The percentage is calculated and replaces the original value in the ongoing computation.
It's possible, I guess, that I just never found out how to use % in the intended manner, but it was pretty surprising to me to see it referred to as common knowledge that four-function calculators were supposedly doing magic with the % key behind the scenes.
Exactly how I feel about MtG (end tangent)
You can prefer RPN all you like, but to think it's objectively better and that parentheses are flat-out bad is crazy. It's a tradeoff. The action of each key is slightly simpler, but you are forced to reorder your equation to change operator application. Sometimes this means keeping track of fewer parts, but sometimes it means keeping track of more.
3 + 4 7 + 8
----- + -----
5 + 6 9 + 2(19 button presses)
Or:
((3 + 4) / (5 + 6)) + ((7 + 8) / (9 + 2))
(27 button presses)
vs on RPN:
+ / + 3 4 + 5 6 / + 7 8 + 9 2 (I think? I don't use RPN)
(15 button presses)
I guess 19 vs 15 button presses is a tradeoff I'm willing to make for easier understanding.
3 (enter) 4 +
5 (enter) 6 + /
7 (enter) 8 +
9 (enter) 2 + / + 3 + 4 = / ( 5 + 6 = + ( 7 + 8 ) / ( 9 + 2 =You forgot the R part of RPN.
Parentheses are common on scientific caclulators and graphing calculators, but as you demonstrate, they add a lot of extra button presses, and you even left out the final "=".
To do this on an RPN calculator, you need nothing beyond the basic 4 functions and the enter key, while you need extra specialized keys like parens or a fraction button to do it on an infix calculator. Taking a look at various infix scientific calculators, they mostly seem to have both parens and a fraction key, so using up the space of 3 keys that an RPN calculator doesn't need and can use for more actual functionality.
Here's how you do it on RPN:
3 <enter> 4 + 5 <enter> 6 + / 7 <enter> 8 + 9 <enter> 2 + / +
You wrote it in Polish notation rather than Reverse Polish Notation, and had left out the enter key that is used as the delimiter between two numbers (pushes a number to the stack, so you can start entering the next number).
I've loved RPN since around 1973 when I paid $395 (plus 7% tax) for an HP-45. I still have an HP-42S that I use.
However, I often find it easier in OS X to just type "python" and go from there. I love Python as an interactive interpreter. It's easy to give good names to intermediate variables. Functions are easily created, starting with "def ...". Etc.
But this works for me because I rarely need sin(), cos(), or stuff like that. It would get tedious to load the Python math functions, to remember the exact spelling of a function. A calculator is good for that, because the keys are right in front of your face. Can't miss 'em.
Most of these are pretty easy -- just do "from math import *" and then you have sin(), cos(), etc. imported into the root namespace.
If you want to explore, you can use something like bpython, do "import math", and just type "math." and it'll pop up a little window showing you the possibilities.
It's like those miserable cheat sheets for electronics that contain:
V=IR
R=V/I
I=V/R
First off, if you don't know Ohm's Law you have no business doing anything with electronics - you're going to use the formulas wrongly. Secondly, if you can't trivially derive the various forms in your head, you have no business using them.That's not what I care about when calculating percentages.
I don't want an inlined relative percentile value, based on prior terms. I almost never need that, and thus never use the percentage key, because that makes it useless and the behavior is counter intuitive.
What if I have a much longer chain of calculations to tally up? What I need, then, is a percentage for one of the terms in isolation, BEFORE I start calculating.
If I have an arbitrarily large number, and an arbitrarily complex percentile value, which makes the percentile value difficult to determine in one's head, I want a button that performs as follows:
37.82726419 percent of 9999.928374666666 equals ???
Which gets keyed as: 37.82726419 % 9999.928374666666 = ???
Then, I take that number and roll it into any other subsequent equations.Too bad the button will never ever work that way, because "tradition."
Using a classic calculator (i.e. one that doesn't obey operator precedence and thus doesn't need parentheses) that's three operators (including "equals") and a total of 10 buttons to press.
56 - 22%
That's 6 buttons to press. Arguably, 6 is less than 10 [citation needed]. But I find it doubtful that this saves a noticeable amount of effort.
If you're multiplying by decimals, you already read "22%" as "0.22" and "-22%" as "(1 - 0.22)". There's no mental overhead in typing that unless you mean rote copying.
Maybe this is a matter of school system priorities. In my country children are introduced to percentages using cross-multiplication. They are also required to write the entire calculation process down in exams in order to pass (to make sure you actually understand the calculation and aren't just blindly entering numbers into a calculator).
They can work out what 8% of 347 is. But ask them what 43 is as a percentage of 172 and they can't do it. Or if a widget costs £250 after a 20% discount, how much did it cost before -- they can't do it.
http://en.wikipedia.org/wiki/Unit_price_information_in_super...
...but even that information is usually printed in a smaller font and can be misleading:
http://talkingcents.consumercredit.com/2011/02/23/unit-prici...
It gives a whole deeper meaning to that classic Barbie utterance: "Maths is hard. Let's go shopping!"
As an example: Reverse an erroneous 10% discount. Use the % button?
I think the calculator in Windows 7 and above took a seriously backwards step in functionality - they seem to have thought that programmers don't need exponentiation nor square roots nor floating-point(!), so there is no such function in "programmer mode" and you cannot change the number base in "scientific mode". That would only be a minor annoyance, if not for the fact that switching between modes clears the accumulator!
http://answers.microsoft.com/en-us/windows/forum/windows_7-w...
It is a classic case of too much modality in UI design. The first time I discovered this "feature" after losing the result of a long calculation, I thought it was a bug or I'd accidentally hit the wrong key. When I found out this was by design, it elicited a loud enough "WTF!?" that caught my co-workers attentions and caused them to exclaim the same thing after showing it to them. Fortunately the calc.exe from XP runs fine on 7 and 8.
There's another "feature" which I hadn't personally run into, but would be just as incensed if I did:
https://social.technet.microsoft.com/Forums/windows/en-US/4e...