> The Windows calculator percent sign works the same way as those cheap pocket calculators
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.
> I never understood how these cheap calculators worked.
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.
Also, in terms of this register machine the percent key performs the operation I = R * I /100, and modifying I causes the display to show the new value of I just like the article mentions:
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.
> I'm glad most serious desktop calculator apps, like the OS X one, have a RPN mode
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.
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.
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.
>With a stack, things are much simpler. You don't need those clumsy memory registers or parentheses
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.
I'm not familiar with the fraction button. Is this common on calculators? I don't see it on most of the basic function calculators that I look at. Hmm, taking a look around, it looks like it might be present on a lot of scientific calculators, but not the basic calculators I see. I had switched to RPN by the time I started using scientific calculators, so I guess I never became familiar with this button.
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.
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 always found it best to stick with a pleasent middle ground. I use a Casio fx82au-plus and it has enough complexity and functionality to suit my needs whilst behaving as expected when anyone in the office asks to borrow a calculator. Otherwise, my iPhone is perfectly capable...
I used to have a cheap pocket calculator, but what I determined through experimentation was that pressing % caused whatever number was on the display to be immediately divided by 100.
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.
My HP-48GX is just as secret-weapon-ish in its fierce programmability. ;)
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.
It's got more memory, though I ended up buying a RAM expansion card as it still wasn't enough. The GX supposedly got the faster processors for a while, until the yield got good enough to also put them in the G models.
After years of using an HP, I am literally unable to use anything but RPN without significant conscious thought. I'm faster with pencil and paper (or an abacus!) than using a non-RPN calculator at this point.
M-x calc is pretty awesome. I had no idea it was there.. (M-x tetris I had heard of)
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.
Really? I haven't heard of any bugs in the command line calculators. Do you know what kinds of bugs they were talking about? One thing to note is that they use arbitrary-precision decimal arithmetic (well, base-100 arithmetic internally, but that's equivalent), rather than fixed precision binary floating point arithmetic, so that may surprise some people (though it also reduces surprise for those who expect decimal arithmetic).
I did some digging. it was in this thread in a comment about bc and exponents (although I can't use a non rpn calculator on computers I just tend to type the formulas in):
Ah, thanks for digging that up. I was not aware that they didn't support fractions in exponents; I don't think I had ever tried them for that. Luckily they do give warnings, though only if you have already set the precision (via "bc -l" or something like "10 k" in dc).
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.
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.
But I never wanted a button that worked like that.
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."
If you don't know math, then yes. Most people don't know or care that "adding 5% tax" is equivalent to multiplying by 1.05. They just know that you have to add 5% for tax. So 72 + 5% makes perfect sense; 72 * 1.05 is terribly confusing.
But that's why most people get stuck with percentages, even if you give them 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.
This actually puts these people at a disadvantage in real life. Just look at the arbitrary packaging sizes and how effective they are at fooling people into thinking they're cheaper or equally expensive just because they're unable to figure out that the "new packaging with 25% extra for free" is actually more expensive than the old packaging that contained a little bit less.
It is. It saves you from an extra mental operation. What's the price of that $56 shirt after 22% off? Doing 1-22/100 in your head adds an extra possibility for error.
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).
I am honestly kind of shocked at the responses to this. We used it in school, I used it at home to figure out sales tax as a kid, I'm honestly shocked so many people don't know what the percent button on a calculator does.
I had no idea because we learned to convert percentages before we were allowed to use calculators in school. So by the time we could have used the % button it was already second nature to read "x + 5%" as "x * 1.05".
I used the % on the calculator as a kid a lot. Then for about 25 years I didn't touch a desktop calculator and was thinking in 75 x 1.05, so when I recently tried to use the percentage sign it didn't work intuitively for me. I tried 75 x 5% and that certainly gave me an answer that felt wrong.
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!
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:
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.