|Re: HP-35 / 35th Anniversary Edition expected soon|
Message #29 Posted by Palmer O. Hanson, Jr. on 13 Apr 2007, 6:08 p.m.,
in response to message #22 by Mike H
You quoted the article as saying
"If you're a frequent calculator user, you owe it to yourself to investigate the advantages of RPN. RPN stands for Reverse Polish Notation. Reverse Polish Notation was developed in 1920 by Jan Lukasiewicz as a way to write a mathematical expression without using parentheses and brackets. Hewlett-Packard Co., realizing that Lukasiewicz's method was superior to standard algebraic(1) expressions when using calculators and computers, adapted RPN for its first hand-held scientific calculator, the HP35, in 1972."
But, if you go to www.woz.org/letters/general/57.html and read to the end you will find the following discussion by Wozniak, the co-inventor of the Apple computer and a former employee at HP:
"... 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. ... "
That's the wonderful thing about history. It seldom tells us what really happened. More often it tells us what the historian would like us to believe. H-P, which doggedly continues to make RPN machines, even when machines with EOS (equation operating systems as on TI and Casio machines) or RPL (as on H-P machines) are clearly better when algebraic expressions are involved, can be expected to emphasize the claimed benefits of RPN to a user. Wozniak, who left H-P to develop the Apple product line which used a higher order language which is far more similar to AOS, EOS and RPL, can be expected to dismiss RPN as a language consistent with the memory limitations of the early 1970's.
The article's example calculation in algebraic mode emphasizes a need to remember an intermediate result. That is, of course, correct for the early machines which mimicked the operation of adding machines. It is not correct for any of the later algebraic machines which implement hierarchy. That's an attempt at salesmanship, I suppose. It will fall flat with any potential user who is familiar with the algebraic machines with hierarchy..
The article also offers an checkbook balancing exercise as a demonstration of the superiority of RPN. With RPN or with an adding machine one enters the last balance, enters a value and presses plus or minus depending on whether the value was a debit or a credit, and sees the result. With algebraic one enters the last balance, looks ahead to see whether the next entry is a debit or credit and enters a plus or minus depending on whether the next entry is a debit or credit, One then enteres the value, looks ahead again to select a plus or minus, and when the plus or minus is entered sees the result of the previous transaction. This means that at the end of the balancing exercise the RPN user will have used exactly one less keystroke. Of course, the "looking ahead" which the AOS user finds natural and appropriate in this case is similar in a sense to the "looking ahead to find a starting point" which the RPN user find natural and appropriate when solving complex algebraic expressions such as the famous Mach Number equation.