advantages of RPN

[Don Shepherd]

I was cleaning up my hard disk drive today and came across this:

Enter versus Equals

I'm not a die-hard RPN fanatic who dismisses every non-RPN calculator as a piece of crap, but I do appreciate the beauty, simplicity, dependability, consistency, and programmability of RPN. To me, the HP-65 was the perfect machine regarding these characteristics. Not that it was faultless, but it did set the standard for those machines that followed it.

Alas, nothing manufactured today can match it.

[Tugdual]

Interesting reading, thanks for sharing this. I personally don't value the number of keystrokes to distinguish RPN from other systems. It was interesting to see that if this number is always lower for RPN, it is not very different (<10%) and shall not explain all.
What matters in my opinion is the user interaction during the calculation. With today calculator, I see kids entering the calculation, i.e. copying what they see on paper to screen and then press '=' or whatever key that performs the whole calculation and gives a result. With RPN, you cannot expect the calculator to do the whole thing for you, you need to think about the way you will approach the calculation and use stack. This is actually a weaker system until you understand that you are part of the solution and can make a difference .

[Jim Horn]

Good points! I consider the difference to be that when using a non-RPN (or RPL) calculator, you are letting it do the math. When using an RPN or RPL calculator, it may be doing the number bashing but *you* are doing the math.

As an engineer who is constantly cranking various equations off the cuff, the latter fits my mental model much better. Especially when a complex calculation involves many intermediate results.

Why, yes, my car does have a manual transmission - why do you ask?

[Dale Reed]

(05-21-2014 09:34 PM)Don Shepherd Wrote:  Enter versus Equals

I had a t-shirt back in college that had:

ENTER^ > =

... with the ENTER^ and = drawn like calculator keys. IIRC, it was gray with blue keys and white legends screen printed. Wore it with pride. I wish I had kept the remnants, but alas... Maybe some day I'll see one on TAS.

Dale

[Didier Lachieze]

(05-22-2014 12:09 AM)Dale Reed Wrote:  I had a t-shirt back in college that had:

ENTER^ > =

... with the ENTER^ and = drawn like calculator keys. IIRC, it was gray with blue keys and white legends screen printed.

Like this one?

[Manolo Sobrino]

I wouldn't take too seriously a 70s leaflet from HP trying to sell their calcs with a certain amount of charming bias. Let's go to 1974? and listen (again...) to a guy that worked there at the time and has "some" skill in technical matters.

Quote:Woz:

Infix to postfix was common to computer scientists in 1970. But this was back when very few colleges even had computer science programs for undergraduates. Postfix notation was not common to average people who use the infix written system. Computer scientists tend to find postfix to be more 'pure' than infix. It does have the qualities of left to right operation and no parentheses. But it requires a stack, which would translate to extra memory steps for a human if we wrote expressions in postfix. I'd guess that computer scientists would feel that early expression writers stuck us with a worse system, kind of like the QWERTY keyboard. The computer scientist view of postfix is similar to the scientists' view of the metric system.

At Hewlett Packard we were so proud that our calculators, the first scientific ones ever, were years ahead of competition. They used postfix partly because the least logic or ROM chips were quite expensive back then. It would have taken extra keys and an infix to postfix translator to use infix. Also, a larger and more expensive desktop HP machine from the division in Colorado Springs used postfix, for the same reasons. The HP-35 was an attempt to miniaturize this machine.

Our marketing department had a card with a monstrous formula to demonstrate how powerful our calculators were and what postfix calculation was capable of. They challenged people to solve it on a slide rule the normal way. Well, we could all solve it on our HP calculators but it took a few tries to get the steps accurate enough, there were so many of them.

Finally Texas Instruments introduced an infix 'algebraic entry' scientific calculator. The first one showed up in our lab one day. We were all pooh-poohing it and laughing at the arithmetic entry as being too weak for engineers. Someone pulled out our big formula challenge and we all laughed, sure that nobody could ever do it with the TI calculator. A challenge went up for someone to try. After a short silence I said that I'd try.

Well I started staring at the formula and looking at the keys and trying to decide which steps to calculate first, as you would do with an HP calculator. I finally realized that I'd never be able to solve the formula this way. With my fellow engineers watching I was very self conscious but I wanted to succeed. I managed to let go of my thinking and then came up with a very amazing concept. I just copied the formula from left to right! This was such an incredible concept that I pressed the keys as fast as I could on the TI calculator, risking a wrong press but impressing my colleagues. I had to guess whether this calculator used the square root button as prefix or postfix but I guessed right and got the proper answer the first time.

My colleagues couldn't believe it. I told them that you just copy the formula from left to right but not one of them could see through their postfix fog. After all, these were the calculator experts of the world. They are well accustomed to thinking ahead and analyzing an expression to come up with the order of steps to take on an HP postfix calculator, and they had to remember which sub-expressions were in what order on the calculator's stack. None of them could do what I had done, forget that they have to be smart.

I was strongly affected for life by this experience. There's a lot of rightness in using the same system on a calculator that we all learn to use on paper, a system that has been around for hundreds of years. My pure side prefers postfix but it's not what I'd recommend to others for a calculator. I also type on a Dvorak keyboard now, but I wouldn't recommend it.

http://archive.woz.org/letters/general/57.html

And he was using an awfully primitive algebraic system (for the Mach number chore I guess). Ten years later the modern expression entry calculators appeared and believe it or not, the war was over.

You can be smart with an expression calculator too. You don't have to copy formulas literally, there's room for technique there. A bit of planning before you write the expressions can make them shorter, some times much shorter. With expressions you can reuse code, which is faster than typing it again and in some cases faster than having to program a macro. If you're not using it again, you can perform interactive calculations by pivoting on a number as in RPN (or in old AOS), now instead of X you have Ans and instead of a fixed stack you store intermediate results in registers/variables, which are meant to be used BTW. You don't have to do that all the time because the precedence rules and the expression capabilities allow you to perform lots of steps in a single line and then store just that result... I wouldn't judge a system by looking at novices while being one myself.

And I think that RPN is great too. It's probably the more efficient way to perform one-time calculations with up to 3-4 levels of stack and then chain calculations. I also think that too much stack gymnastics blurs the original calculations in your mind and turns them into a juggling game, that's why I wouldn't recommend it to people who are still learning the basics.

There's no need to dismiss any tool in the box. Sometimes though, as some HP calculators have a complex design for the sake of it really, it's funny to see the amount of confusion generated by it and then how other systems are being discarded for being too simple and "for kids". Well, maybe you can have easy to understand calculators that work without friction. That's why there are not very interesting forums about them: they just work as expected and people get things done. I don't think that there are many things to write about how to use a Casio 115ES... Had the Prime worked as expected the Prime forum would be half the size (at least) .

[Don Shepherd]

(05-22-2014 12:39 AM)Manolo Sobrino Wrote:  I wouldn't take too seriously a 70s leaflet from HP trying to sell their calcs with a certain amount of charming bias. Let's go to 1974? and listen (again...) to a guy that worked there at the time and has "some" skill in technical matters.

Quote:Woz:

Infix to postfix was common to computer scientists in 1970. But this was back when very few colleges even had computer science programs for undergraduates. Postfix notation was not common to average people who use the infix written system. Computer scientists tend to find postfix to be more 'pure' than infix. It does have the qualities of left to right operation and no parentheses. But it requires a stack, which would translate to extra memory steps for a human if we wrote expressions in postfix. I'd guess that computer scientists would feel that early expression writers stuck us with a worse system, kind of like the QWERTY keyboard. The computer scientist view of postfix is similar to the scientists' view of the metric system.

At Hewlett Packard we were so proud that our calculators, the first scientific ones ever, were years ahead of competition. They used postfix partly because the least logic or ROM chips were quite expensive back then. It would have taken extra keys and an infix to postfix translator to use infix. Also, a larger and more expensive desktop HP machine from the division in Colorado Springs used postfix, for the same reasons. The HP-35 was an attempt to miniaturize this machine.

Our marketing department had a card with a monstrous formula to demonstrate how powerful our calculators were and what postfix calculation was capable of. They challenged people to solve it on a slide rule the normal way. Well, we could all solve it on our HP calculators but it took a few tries to get the steps accurate enough, there were so many of them.

Finally Texas Instruments introduced an infix 'algebraic entry' scientific calculator. The first one showed up in our lab one day. We were all pooh-poohing it and laughing at the arithmetic entry as being too weak for engineers. Someone pulled out our big formula challenge and we all laughed, sure that nobody could ever do it with the TI calculator. A challenge went up for someone to try. After a short silence I said that I'd try.

Well I started staring at the formula and looking at the keys and trying to decide which steps to calculate first, as you would do with an HP calculator. I finally realized that I'd never be able to solve the formula this way. With my fellow engineers watching I was very self conscious but I wanted to succeed. I managed to let go of my thinking and then came up with a very amazing concept. I just copied the formula from left to right! This was such an incredible concept that I pressed the keys as fast as I could on the TI calculator, risking a wrong press but impressing my colleagues. I had to guess whether this calculator used the square root button as prefix or postfix but I guessed right and got the proper answer the first time.

My colleagues couldn't believe it. I told them that you just copy the formula from left to right but not one of them could see through their postfix fog. After all, these were the calculator experts of the world. They are well accustomed to thinking ahead and analyzing an expression to come up with the order of steps to take on an HP postfix calculator, and they had to remember which sub-expressions were in what order on the calculator's stack. None of them could do what I had done, forget that they have to be smart.

I was strongly affected for life by this experience. There's a lot of rightness in using the same system on a calculator that we all learn to use on paper, a system that has been around for hundreds of years. My pure side prefers postfix but it's not what I'd recommend to others for a calculator. I also type on a Dvorak keyboard now, but I wouldn't recommend it.

http://archive.woz.org/letters/general/57.html

And he was using an awfully primitive algebraic system (for the Mach number chore I guess). Ten years later the modern expression entry calculators appeared and believe it or not, the war was over.

You can be smart with an expression calculator too. You don't have to copy formulas literally, there's room for technique there. A bit of planning before you write the expressions can make them shorter, some times much shorter. With expressions you can reuse code, which is faster than typing it again and in some cases faster than having to program a macro. If you're not using it again, you can perform interactive calculations by pivoting on a number as in RPN (or in old AOS), now instead of X you have Ans and instead of a fixed stack you store intermediate results in registers/variables, which are meant to be used BTW. You don't have to do that all the time because the precedence rules and the expression capabilities allow you to perform lots of steps in a single line and then store just that result... I wouldn't judge a system by looking at novices while being one myself.

And I think that RPN is great too. It's probably the more efficient way to perform one-time calculations with up to 3-4 levels of stack and then chain calculations. I also think that too much stack gymnastics blurs the original calculations in your mind and turns them into a juggling game, that's why I wouldn't recommend it to people who are still learning the basics.

There's no need to dismiss any tool in the box. Sometimes though, as some HP calculators have a complex design for the sake of it really, it's funny to see the amount of confusion generated by it and then how other systems are being discarded for being too simple and "for kids". Well, maybe you can have easy to understand calculators that work without friction. That's why there are not very interesting forums about them: they just work as expected and people get things done. I don't think that there are many things to write about how to use a Casio 115ES... Had the Prime worked as expected the Prime forum would be half the size (at least) .

Manolo, thanks for that story by the Woz, it is a great perspective on this topic. When the Macintosh was introduced in January of 1984, my local computer user's group, Washington (DC) Apple Pi, brought Woz to town, along with Andy Hertzfeld as I recall, and they showed us what that original Mac could do; it was truly revolutionary. I left that meeting and went directly to my local computer store (yes they had those in 1984) and ordered a 128k Mac. Prior to that, I had an Apple ][+, which was also a Woz creation, of course. He is a legend, and deservedly so.

[Garth Wilson]

(05-21-2014 10:20 PM)Tugdual Wrote:  Interesting reading, thanks for sharing this. I personally don't value the number of keystrokes to distinguish RPN from other systems. It was interesting to see that if this number is always lower for RPN, it is not very different (<10%) and shall not explain all.

They did not compare to units with parentheses (like the TIs I started with); but even there, the comparisons in ads in the early 80's were sometimes invalid, for example:
(sin(n4^(n3*(n1+n2))))=
ignored the fact that the = key would close all the levels of parentheses at once, so a keypress count should not have included the )))).

However, the algebraic one cannot re-use intermediate parts of the equation without storing them in a variable for later retrieval; whereas with a stack, you can dup it. Things get hairy when you have lots of parts of a program needing temporary variables. Is a particular one free at the moment, or will I step on something still needed by a pending routine? It may be fine now, but what happens if I have to come back later and modify it? Did I document well enough which ones were used where, and when, or will it mess up and then a part I didn't touch quits working, because I used its temporary variable in my other modified routine? It can be a debugging nightmare. A stack reduces the need for variables, and makes program maintenance much easier. These temporary variables cease to exist when they're no longer needed.

Quote:What matters in my opinion is the user interaction during the calculation. With today calculator, I see kids entering the calculation, i.e. copying what they see on paper to screen and then press '=' or whatever key that performs the whole calculation and gives a result.

Educators fail to realize that this is not the usual situation in life though. In real life (I'm in EE), you usually don't have an equation in front of you on paper. You figure out what you need as you're punching buttons.

[Dale Reed]

(05-22-2014 12:25 AM)Didier Lachieze Wrote:  

(05-22-2014 12:09 AM)Dale Reed Wrote:  I had a t-shirt back in college that had:

ENTER^ > =

... with the ENTER^ and = drawn like calculator keys. IIRC, it was gray with blue keys and white legends screen printed.

Like this one?

MY SHIRT!!! COME HOME TO DADDY!!!

[Thomas Klemm]

(05-22-2014 12:09 AM)Dale Reed Wrote:  ENTER^ > =

Why didn't they use post-fix notation?

[rprosperi]

(05-22-2014 01:55 AM)Thomas Klemm Wrote:  

(05-22-2014 12:09 AM)Dale Reed Wrote:  ENTER^ > =

Why didn't they use post-fix notation?

Reminds me of the bumper sticker in the early 80's:

FORTH [LOVE] IF HONK THEN (where [LOVE] was a heart symbol).

I still have one of those bumber stickers somewhere...

[Mike Morrow]

(05-21-2014 10:20 PM)Tugdual Wrote:  I personally don't value the number of keystrokes to distinguish RPN from other systems. It was interesting to see that if this number is always lower for RPN, it is not very different (<10%) and shall not explain all.

That less than ten percent difference that you cite is inaccurate in the extreme, in my personal and fairly extensive contemporary experience.

In 1977 I purchased the new HP-67 (the first HP that I owned, and the first RPN programmable I'd ever used) and the new TI-59 (my third TI programmable, after a SR-52 and SR-56). I was experienced with TI programming well beyond my familiarity with HP RPN programming.

I wrote equivalent programs for both machines for use in the engineering department of a USN nuclear submarine between 1977 and 1979. The USN used NO digital computers in its nuclear propulsion plants of that era. My programs performed such tasks as nuclear power plant calorimetric, machinery vibration data processing, radiological laboratory analysis calculations, and others. For ship driving, I wrote several programs, such as calculating bearing and distance for closest point of approach.

These were professional-use, frequent-use programs, not programming exercises. I consistently found, without exception ever, the number of steps that the HP-67 required for any specific process was about 65 percent of the steps required by the TI-59. That 35 percent differential in the HP's favor was very helpful because the HP-67 had far less RAM than the TI-59. The biggest advantage of the TI-59 was its memory size, and much more...the PC-100A print cradle. The advantage of the PC-100 was so great that I intended to settle on the TI-59 as my standard machine for these shipboard tasks. But the TI hardware was far far less reliable than that of the HP-67, with several failures experienced in a one-year period of either the TI-59 or PC-100A for critical service needs. I was forced to use only the HP-67, which never failed, for every task. Eventually I was able to get the ship to purchase an HP-97 to get printer capability.

[Les Bell]

(05-22-2014 01:25 AM)Garth Wilson Wrote:  Educators fail to realize that this is not the usual situation in life though. In real life (I'm in EE), you usually don't have an equation in front of you on paper. You figure out what you need as you're punching buttons.

Exactly. In back-of-the-envelope stuff, you're working things out as you solve a problem. In your mind, you're thinking, "So that means the current in this branch is ...", and then you think, "Yes - that seems reasonable. And so the power dissipated in this resistor will be ...". An RPN calculator keeps what you're working with right in front of you, and you can use it as you reason through a problem. You're not simply evaluating a series of equations.

This, to me, is the power of RPN - quite often, the intermediate values you see as you work inside-to-outside through a calculation (and which the algebraic user never sees) have meaning, and you can check whether they seem plausible, allowing you to pick up any errors and work with more confidence.

[Nigel (UK)]

(05-22-2014 01:25 AM)Garth Wilson Wrote:  However, the algebraic one cannot re-use intermediate parts of the equation without storing them in a variable for later retrieval; whereas with a stack, you can dup it. Things get hairy when you have lots of parts of a program needing temporary variables. Is a particular one free at the moment, or will I step on something still needed by a pending routine? It may be fine now, but what happens if I have to come back later and modify it? Did I document well enough which ones were used where, and when, or will it mess up and then a part I didn't touch quits working, because I used its temporary variable in my other modified routine? It can be a debugging nightmare. A stack reduces the need for variables, and makes program maintenance much easier. These temporary variables cease to exist when they're no longer needed.

I like RPN a lot, but my Prime is set to algebraic mode. What I like so much about algebraic mode on the Prime (and on calculators like the TI NSpire, TI-89, etc.) is that there is a visible and re-usable history of all calculations. I virtually never need to use variables to store results because previous results - and the calculations that led to them - are always available. I still need variables in programs, but with the Prime's structured language variable conflicts aren't a problem. RPN has real advantages on a single-line display machine but on the Prime I like algebraic better.

Nigel (UK)

[Alvaro]

Let me say like this: There are much better options.

If the HP50g had a BASIC language on it I am sure it would be the "Ultra Calculator of the Century".

My personal opinion is that it will be very difficult to find something worst than UserRPN as a "programing Language".
While I agree that for manual calculations there is some advantage of PRN, I even like it, but as a "Programing Language" is the worst I can imagine.

UserRPL is very difficult to read, to follow.
UserRPN makes heavy usage of the stack. So, while READING or PROGRAMING you have to do a big effort to follow what is happening on the Stack what makes it much difficult to read, besides the huge usage of all sort Brackets.

Not forgetting the unpossibilty of programing on a Desktop PC, run it there and transfer the ready Programm to the HP

I disagree of the advantage people are saying about "user interact" with stack. For me that is something like "marketing".

[Don Shepherd]

(05-22-2014 03:08 PM)Alvaro Wrote:  Let me say like this: There are much better options.

If the HP50g had a BASIC language on it I am sure it would be the "Ultra Calculator of the Century".

My personal opinion is that it will be very difficult to find something worst than UserRPN as a "programing Language".
While I agree that for manual calculations there is some advantage of PRN, I even like it, but as a "Programing Language" is the worst I can imagine.

UserRPL is very difficult to read, to follow.
UserRPN makes heavy usage of the stack. So, while READING or PROGRAMING you have to do a big effort to follow what is happening on the Stack what makes it much difficult to read, besides the huge usage of all sort Brackets.

Not forgetting the unpossibilty of programing on a Desktop PC, run it there and transfer the ready Programm to the HP

I disagree of the advantage people are saying about "user interact" with stack. For me that is something like "marketing".

Alvaro, programming languages exist to enable people to solve problems on computers. A programmable calculator is a computer. I probably wouldn't try to write a payroll program on a programmable calculator, but there are all kinds of problems that lend themselves to solution on a calculator, and an RPN calculator is a suitable device for such problems.

A forum user sent me a copy of the HP-65 User's Library Catalog, dated April, 1975, which is 15 months after the HP-65 was introduced. This catalog lists programs written by HP-65 users, to be shared with other users. In those 15 months, approximately 600 users submitted approximately 2,000 RPN programs. Those were useful programs for solving real problems. In 1975, NASA developed RPN programs for the HP-65 carried aboard the Apollo-Soyuz Test Project, which would have been used had the onboard Apollo Guidance Computer failed.

HP has not made an RPN calculator--other than the venerable 12c--in many years, but there are lots of people out there today, in 2014, using RPN calculators and writing useful routines for their application area. And there are many members of this forum doing the same. I have written probably a few dozen HP-65 programs to help me as a math teacher. Forty years later, it is still going strong!

Like I said, I wouldn't write a payroll program on my 65, but RPN programs are both valid and useful.

[Les Bell]

(05-22-2014 03:08 PM)Alvaro Wrote:  My personal opinion is that it will be very difficult to find something worst than UserRPN as a "programing Language".
While I agree that for manual calculations there is some advantage of PRN, I even like it, but as a "Programing Language" is the worst I can imagine.

There is no such thing as a "best" or "worst" programming language in absolute terms; a versatile programmer knows several or many, and picks them up and puts them down as appropriate to the task at hand. I do some things in Java, some in C++, some in Python and some as bash scripts. Recently I had to dig into some LaTeX code and write a document class, and trust me - as a programming language, TeX/LaTeX makes RPN look absolutely luxurious. But it was the best way of solving my problem.

For programming, RPN occupies a similar niche to bash. The user learns his way around the command line, picks up tools like wc, ls, grep, etc. and then wants to automate some repetitive processes - and shell scripts provide a way of doing that. Similarly, RPN keystroke programming provides a natural way of automating tedious calculations. I find it quite appropriate to the handheld calculator environment. If I want something with more expressive power, then I'll turn to a computer or tablet with one of the languages above.

But it's amazing how often some paper-and-pencil explorations of a problem lead naturally into a short RPN program that gives the desired answer.

[Garth Wilson]

(05-22-2014 09:44 AM)Nigel (UK) Wrote:  

(05-22-2014 01:25 AM)Garth Wilson Wrote:  However, the algebraic one cannot re-use intermediate parts of the equation without storing them in a variable for later retrieval; whereas with a stack, you can dup it. Things get hairy when you have lots of parts of a program needing temporary variables. Is a particular one free at the moment, or will I step on something still needed by a pending routine? It may be fine now, but what happens if I have to come back later and modify it? Did I document well enough which ones were used where, and when, or will it mess up and then a part I didn't touch quits working, because I used its temporary variable in my other modified routine? It can be a debugging nightmare. A stack reduces the need for variables, and makes program maintenance much easier. These temporary variables cease to exist when they're no longer needed.

I like RPN a lot, but my Prime is set to algebraic mode. What I like so much about algebraic mode on the Prime (and on calculators like the TI NSpire, TI-89, etc.) is that there is a visible and re-usable history of all calculations. I virtually never need to use variables to store results because previous results - and the calculations that led to them - are always available.

What I meant was when you need a portion again in the same equation, like (a+b)/(a+b+c) for a simple example.

Alvaro Wrote:Let me say like this: There are much better options.

If the HP50g had a BASIC language on it I am sure it would be the "Ultra Calculator of the Century".

My personal opinion is that it will be very difficult to find something worst than UserRPN as a "programing Language".
While I agree that for manual calculations there is some advantage of PRN, I even like it, but as a "Programing Language" is the worst I can imagine.

UserRPL is very difficult to read, to follow.
UserRPN makes heavy usage of the stack. So, while READING or PROGRAMING you have to do a big effort to follow what is happening on the Stack what makes it much difficult to read, besides the huge usage of all sort Brackets.

Not forgetting the unpossibilty of programing on a Desktop PC, run it there and transfer the ready Programm to the HP

I disagree of the advantage people are saying about "user interact" with stack. For me that is something like "marketing".

I have two HP-71's, which, with the math module and the LEX file contributions from the users' groups, have by far the best BASIC I've ever seen; yet for math-type programming, I still prefer the 41. I write the programs in a text editor on the PC though, so I can group associated instructions on a line, indent loops, add comments, etc., before keying them into the 41. Then they usually work on first try, unlike the situation with the 71. When I try to do things on the 71 in BASIC, my debugging partly consists of counting parentheses to figure out why it didn't like what I typed in. It can be a bit difficult sometimes. I'd rather do it in RPN, and I have no trouble keeping the image of what's happening on the stack in my mind. Even my assembly-language programming for microcontrollers for commercial products is becoming RPN-like, with stacks. I really don't want any more algebraic languages. I'm done with them. People don't all think the same; but although different languages might me more natural or unnatural for different people, I think people can gain skill in something that was previously unnatural. I understand RPN is very natural for native Korean speakers, because their spoken language is very RPN.

[Thomas Radtke]

Without appropriate studies as backup, just as a personal observation: RPN, nomographs, slide rules, tables etc. give some kind of access to numbers that generations using current calculators don't have. I expect students with mild forms of dyscalculia to have much more problems identifying and approaching their desease.

[Matt Agajanian]

(05-21-2014 09:34 PM)Don Shepherd Wrote:  I was cleaning up my hard disk drive today and came across this:

Enter versus Equals

I'm not a die-hard RPN fanatic who dismisses every non-RPN calculator as a piece of crap, but I do appreciate the beauty, simplicity, dependability, consistency, and programmability of RPN. To me, the HP-65 was the perfect machine regarding these characteristics. Not that it was faultless, but it did set the standard for those machines that followed it.

Alas, nothing manufactured today can match it.

Thanks for the linkup. That brochure is a top five favourite of mine. Extra thanks that you found the colour version!!