But an app doesn’t have the feel of HP’s keys, which were the best.
Yes, and a digital SLR takes fantastically better pictures than a cell phone camera. But I carry my phone everywhere, while my Nikon and HP48 stay at home, except for special occasions.
Back in the day . . .
I was a senior (or maybe a junior) in High School when Hewlett Packard came out with their first “programmable calculator”. I’ve long since forgotten the model number. They placed several in various high schools, and we got one. Of course, it used RPN.
(ETA: This was in 1968 or 1969.)
This early programmable calculator was far from being “pocket” sized. It was about the size, shape, and weight of a typical desk-top electric typewriter of the day. It had a 7-segment digital display that showed the top three numbers (called X, Y, and Z) of the stack.
Its memory and program capacity were quite small, certainly compared to anything today. A program could be about 128 steps or so. It came with an optical card reader and a supply of IBM-card sized cards with rows of bubbles on them that you could fill in to record a program. I think there was a printer available, but we didn’t have that.
It had all the basic and scientific functions. I don’t recall if it had basic one-variable statistical function. Definitely no bivariate functions, and no advanced functions like integration or graphics.
It was ensconced in one math teacher’s classroom. He left his room open at lunch, and there were a few (like, 3) nerdy types who hung out there and played with it. That was my first introduction to computers, and led me to go into computer science when I went to college a year or so later.
Did that desktop look like any of these?
If so, I remember playing with one a long, long time ago in a museum. You can find technical details at the HP Calculator Museum site:
http://http://www.hpmuseum.org/hp9100.htm
I still have a HP-11c and it still runs great although the keys sometimes have to be pressed a couple of times to register. I think this is mostly due to lack of use than wear. By the way, that Calculator Museum is a fascinating site and has a lot of interesting details on all of the classic HP calculators:
My first calculator was a texas instruments sr-50a.
I used it up until the mid 90’s. Battery wouldn’t take a charge anymore and it got thrown out.
I didn’t have a data structures class in high school. My brother and sister had RPN calculators when they were in high school (I was still in elementary school at that point, late 1970’s), and I just didn’t get what the big deal was. A “regular” calculator made sense: at school I was learning my multiplication/addition tables, and repeatedly saw “a+b=c” and “x*y=z” on the printed page, so a calculator that let you enter that exact same character sequence made more sense to me.
It was probably significant that their calculators had a one-line display, so you could only see the last (first?) number on the stack. By high school I understood that the calculator held more numbers that couldn’t be seen, but the hassle of remembering what those numbers were struck me as asking for trouble.
It wasn’t until I got to college and saw the HP48 that I started to realize the possibilities. It had a multi-line display, so you could see four or five lines of the stack at once. There were commands/keys for moving entries up or down on the stack with ease. I ended up getting one of these and became adept at programming it. I used it throughought most of my undergrad and all of grad school.
Now I hate “conventional” calculators. I still have the HP48, but I don’t use it much now because I have a PC and have installed RPNcalc (I didn’t have a PC until my final two years of grad school). If I had a “smart” phone, an RPN calculator would be one of the first apps I would install.
This raises an interesting point. If you are thinking about evaluating something, RPN is the more straightforward approach. But, if what you are doing is just copying something from a printed page, of course it is easiest to literally copy it. This is like the difference between being a writer and being a typist.
The computer language Forth is stack oriented. You could say it uses RPN, though there are some distinctions like “stack lift enable/disable” if you are being very precise.
Leo Brodie, author of the famously Starting Forth, comments that there are some things that stacks are very clumsy for, and gives the example of starting with minimum and maximum values for X and Y, and ending with (X,Y) coordinat pairs for all the corners of a box. I think it is true that there is no one best notation for all purposes. That said, RPN is hard to beat as a general purpose notation.
It’s not dead. As others have noted, HP has recently re-released a special edition of at least one RPN calculator. My dad had been using his original for over thirty years and got himself a new one.
I’m the same way. My first RPN calc was the HP-25 which got me through engineering school. My last RPN calc was the HP-15C. I still have both of them but today I mostly use an HP-41 emulator on my Android and Grpn on my Linux desktop.
There’s something I’ve always wondered about PN/RPN – are there semantics for working with things like variables, derivatives, and integrals in them? It seems less straight forward. The best I can think of is something like
dx 2 x pow x add 5 0 integrate (integrates x^2+x from 0 to 5 with respect to x).
Where “integrate” is sort of a variadic instruction that pops expressions off the stack until it hits a “dx” which acts as a terminator, but I don’t know if there’s something more standard that’s used.
Exactly. RPN had nothing to do with being more user friendly, or more intuitive or anything that had dick to do with the user.
It was simply a much easier method to implement a calculator with the hardware available at the time.
So I say good riddance. It was a pain in my ass in graduate school because those damn HP financial calculators only used RPN, and I loathe that stupid, unintuitive way of doing it.
Seriously… putting 2 <enter> 2 + to get 4 is a lot screwier than 2 +2 <equal>, and it gets worse if you have to do more complicated things.
(and FWIW, I have a computer science degree, and we covered how to implement RPN in a stack in architecture class, but I always hated it anyway. I just don’t think of adding 3 + 4 “Take 3 and 4 and add them together to get 7”. I think of it as “3 plus 4 equal 7”.)
Remember back in second grade when you wrote
2
5
7
That’s RPN. FWIW, I find “algebraic calculators” drive me nuts. RPN is really the natural way to go. When I used to do income tax returns by hand, I don’t think I could have managed without my trusty RPN calculator. Usually, whenever I needed a number, there it was on the stack.
For what it’s worth the big difference is that if you plugging numbers into a formula written in the usual way, then an algebraic calculator is better, but if you are working something out in your head, RPN is the way to go. I have installed Co-Calc, an RPN calculator on every computer I have owned in the past 15 years. It is free. My favorite computer language was Forth, a stack based rigidly RPN language.
I found RPN more intuitive. Where it really shined was in my material science class where we had to calculate these ridiculously long expressions. Where the algebraic guys had to keep track of how many parenthesis and pending operations they had going, the rpn dudes simply had to manage a stack. It’s simply more intuitive to have pending values than pending operations. I always had the utmost confidence in my results.
And yeah, the number you need is often right there on the stack. Funny how that works.
My first job as an electrical engineer was for a company that made handheld computers and the programming language was FORTH. Huzzah!
Au contraire. Handheld calculators are alive and well in schools, where using phones during class/tests is frowned upon.
(R)PN is just notation. Semantics are what they’ve always been. So, sure, if you would normally think of integration as given by a function Integrate(dx, x^2 + x, 5, 0), then you would write that in RPN notation in the manner you note [well, I suppose you were probably thinking originally Integrate(0, 5, x^2 + x, dx), but there’s no need to reverse the order of the arguments in going to RPN; the only thing that’s “reversed” is that, in a function call, the function name comes after its arguments, rather than before or inbetween them].
That having been said, you probably shouldn’t think of integration as given by a function like that; you should probably think of integration as given by a higher-order function Integrate(0, 5, the function which sends any input x to the output x^2 + x), which accepts a function as one its arguments, and doesn’t care, or even have any awareness of, what you name your variables. Then you would need constructs for creating functions. And you can make up whatever notation you like for those constructs; this would be an entirely orthogonal matter to whether you put function names before, after, or inbetween their arguments.
Also, note that there’s no need for a “variadic instruction that pops expressions off the stuck until it hits a… terminator”. What you wrote works perfectly well thinking of integrate as just taking 4 arguments, all the time. You’ve put on the stack [dx, x^2 + x, 5, 0]; the entire expression specifying the function to be integrated is contained in one slot on the stack.
So, in prefix notation (PN), I might ordinarily write Integrate(0, 5, [x |-> Add(x, Pow(x, 2))]), where “[x |-> …]” is just a fancy pants way of saying “The function which, given an input I will for now call x, produces output so-and-so”. (Some people like to write this as “[lambda x …]” instead, scaring other people who don’t like Greek letters. It’s all the same.)
And in postfix notation (RPN), I would write this instead as (0, 5, [x |-> (x, (x, 2)Pow)Add])Integrate. [In both cases, dropping the superfluous parentheses around/commas between function call’s arguments if I liked]
If you didn’t like having the [x |-> …] construct, and wanted to avoid talking about named variables altogether, you could get by with other constructs for specifying functions just as well [e.g., combinators]. But this would be orthogonal to the issue of prefix vs. postfix vs. infix notation for function calls.
RPN is a gift from the Gods to man.
My HP 48G I received as a gift in 1996 is still going strong. And like others, I have the emulator on my phone.
I wouldn’t go that far. Postfix (and prefix) notation does have an advantage over infix notation in that it can unambiguously represent operator precedence without “rules” or parentheses. In that way postfix is objectively simpler than infix, and that is why old computers implemented it first.
Infix notation seems more natural to humans because almost universally that’s how we learn it. If grade-schoolers were taught postfix, then postfix would seem natural.