Off Topic — HabitableZone

Off Topic » in reply to My calculator

re: My calculator
Robert — (archived)

My HP calculator's so old the little model number plate's fallen off, but I'm sure it's an HP4x. Other calculators have come and gone over the years, but that thing keeps working year in and year out. I've only had to change the battery once in all these years, and I remember it as kind of a shock. I'd come to take the calculator so much for granted that a dead battery wasn't my first guess, and I felt a pang at the thought that it had finally broken. Battery? It's an HP, it draws sustenance from the very fabric of the universe (ZPE?) and its ability to always produce an answer is written in natural law. HP doesn't need anything as common as a battery.

(But that was the Hewlett-Packard of yesteryear, a sadder trip down memory lane. Damn Fiorina.xls anyway.)

RPN is one of those odd little footnotes in the history of technology, a path not taken for cultural reasons. From a programmer's perspective, RPN is computationally far more efficient than conventional syntaxes, but because of centuries of tradition of mathematical notation, almost all computer languages use a math-like notation that's a tangled rat's nest from the point of the view of the computer. Consider the canonical assignment statement:

A = 2 + 3

The interpreter or compiler encounters the reference to variable A and has to set it aside. It encounters the equal sign and takes it as a clue that it will soon be performing an assignment. It has to set aside the 2 because string length != 0 yet. The + is a promising sign (unintentional pun, I promise), but implies yet one more argument to go. Finally encountering the 3, the computer can solve 2 + 3, unwind to = which points it back to the reference to A, where it stores the result.

In contrast in RPN:

2 3 +

is handled in stride in the forward direction by pushing the two numbers on to the stack and executing + to add them and place the result back on the stack. Variables tend to get grafted on to RPN languages for convenience but they're "ideologically impure", and in truth if you're careful you can juggle the stack and move pieces around like one of those sliding puzzles (altering the order of stack items with verbs like swap, dup, and rot to move items into position) and get everything done using only the stack.

In the 70s I used an RPN language called Forth. Almost nobody remembers it, which is ironic, considering that PostScript is a Forth vocabulary; considering the number of Forth programs thus run each day as PostScript print jobs or PDF documents, Forth is hands-down the most successful computer language of all time.

It was popular in the early days of anemic computers precisely because it was so efficient. It was said, with some truth, that a skilled Forth programmer could produce an application that was actually smaller than its functional equivalent written in assembly language. Even working at the level of assembly languages, programmers naturally structure the software like higher level languages, which embody some of the kinks of mathematical notation, which burdens even assembly with overhead. Forth with its smooth RPN action ran closer to the bone, more in tune with the underlying hardware.

There will always be a low end to computer power at any given time, and Forth survives in niches like programmable controllers and computer games. Memory and speed will always be tight in those niches, and that's where Forth will hang around for a long time. Gosh, now that I think about it, since one purpose of PDF is to be an archival format for electronic documents, Forth will get dragged down through the centuries along with PostScript. Life is funny that way.

Log in or register to post.

The whole thread (114 posts)