Explain why RPN is so much better than infix. Explain why the simple, distraction-free BASIC impl is so liberating for certain kinds of tasks. Explain what kinds of tasks this little gizmo enables and why are these tasks better on the gizmo than on a more "modern" alternative. Riff on the weeks of battery-use, the lack of push notifications, the cool retro factor...any of this to convey the coolness that is the gizmo.
Nice little one-off piece, but I'd love to see something similar with more passion and explanation!
But I also find excuses to put switches and dials on things and am the kind of person to think screen based aircraft cockpits are a regression.
After reading, I discovered the macOS calculator supports RPN (Cmd+R) and it is about as cool as described. Looks like the iPhone calculator does not but I'm sure there are great apps.
The MacOS calculator's RPN mode is annoying. They don't get stack lifting right.
Suppose you want to compute sqrt(12) + pi.
Starting from an empty stack, this will do it on an HP calcualtor, PCalc, both RPN calculators I downloaded from the Windows Store, and, well, pretty much every RPN calculator I've used except from Apple:
1 2 SQRT Pi +
On the MacOS calculator, the Pi overwrites the sqrt(12).
If you do it this way:
1 2 SQRT 3 . 1 4 1 6 +
One other difference to watch out for. On some calculators, this:
2 ENTER +
On others, it will give a missing operand error. This includes the HP-48 family. On these calculators, number entry does not take place in X. It takes place in some sort of input buffer, and ENTER pushes that onto the stack so it ends up in X. So the "2" goes into the input buffer, ENTER signifies you've finished and 2 goes to X. X was empty before so nothing gets pushed to Y. So you've only got one operand and the "+" fails. (On these calculators, operators other than ENTER implicitly insert an ENTER first if the input buffer is not empty).
I'm not sure why HP changed this. The older calculators only had 4 stack positions, no entry buffer, and the display only showed X. By the time of the HP-48 they had many many more stack positions, an entry buffer, and the display could show the bottom 4 stack positions (or the bottom 3 and the entry buffer during digit entry). Perhaps the HP-48 behavior is what they always wanted, but decided it would be too confusing on the older calculators where your visibility was limited.
PCalc and MacOS calculator are like the HP-15C. PCalc has an "HP 48 Style" option on the advanced settings page if you prefer the HP-48 behavior.
I'm similar. I have my HP 49G sitting on the desk near me. Don't use it much, which makes me sad.
I have several things I like more about RPN. Especially over infix, it is a bit easier for me to decompose what I'm doing. Especially since I can't stand the arrow keys to jump around the bloody equation as I'm entering it. That said, I don't think it is "de facto" superior. I do like it, though.
At least in my experience, it allows easier reuse of previous values. This makes RPN based calculators easier to use for exploratory kinds of work.
I use RPN Calculator v1.3 by Bill Menees, I find the interface a lot cleaner that the others I've tried.
But you can't replicate that bit with a computer program too well.
I wanted a calendar, and found one online but it was very slow. It was written entirely in the User RPL. So I wrote my own, also entirely in RPL, but managed to get it fast enough that there was no perceptual difference between its speed and the speed of assembly language calendars.
I got the speed by managing to do almost all of the formatting, which was the slow part, using User RPL string functions, which were all internally implemented as highly optimized assembly.
I'd start with these two strings (spaces replaced with _ for clarity):
days = "__1__2__3 ... _29_30_31"
pad = "_____________________" (that's 21 spaces)
Then I'd calculate
s = number of days month is shorter than 31 days, and
d = day of week of 1st day of month (Sunday == 0, Monday == 1, ...).
Shorten the days string by 3 * s, and prepend 3 * d spaces on front of days (which can be obtained by taking an appropriate substring of the pad string). Finally, append the pad string to days.
Display a header line:
Now take the first 21 characters of days and display them on the next line under the header, then the next 21 characters on the next line, and so on for 5 lines, and that's your calendar.
This could probably be improved a bit by starting with a days string that has 18 spaces in front and 12 spaces at the end. Then you just have to possibly replace some numbers with spaces if the month is shorter than 31 days, and then use the day of the 1st to choose where you start taking the 21 character substrings from.
With that said, there are some technical aspects of the 48 series that were particularly gratifying. The unified programming model (RPL all the way down to assembly) and focus on customization made it easy to extend the calculator in interesting ways. (ie: I remember writing a reasonable improvement to the stack display in a couple hundred bytes of user code, etc.)
The USAG command was another fun example. The HP48's programming language was dynamically typed... every user command had a standard type check/dispatch prologue at the beginning of its code that would check the arguments on the stack and dispatch to the right block of code based on types. What USAG did was to take the name of a command, inspect the code to look for what combinations of types it could accept, and then present those in the UI a form of 'online help'. (Editing RPL programs worked similarly... the calculator didn't retain the text of a program you entered, it would reconstitute the text by inspecting the 'compiled' code).
Reading back over those examples, they aren't the kind of thing you'd expect to write about a calculator... which is part of what made the HP48 series so much fun.
SwissMicros has a range of credit card sized calculators that are so close to what I want. However they are running hp firmware in emulation and I don't believe that any of the firmware they are using have an equation solver.
We have the technology now to make an advanced pocket sized calculator I'm sure. Why does no one want to release one? The calculator enthusiast community seems content with just emulating 30 year old calculators and everyone else is just selling calculators for people that need to take standardized tests.
DMXXL: Same size and features as HPXXC
DMXX: Credit-card sized HPXXC (but full sized display)
They all appear to take cr2032 batteries.
The 42 can run off of USB power (and will clock higher when doing so). It is unclear if the portrait calculators will as well.