▼
Posts: 5
Threads: 1
Joined: Jan 1970
Hi,
I just found my dad's old 42s, and am trying to learn RPN.
I understand RPN fine. The main problem I have is dealing with the limited 4level stack.
eg. How do i input this?
42  12( (4+2)/3 + (3+2)/6 ) = ?
i don't have a deep enough stack!
Thanks for your help.
Cuppo
PS: I'm looking for an answer that doesn't involve rearranging the terms. During an exam, the number crunching part should be a nobrainer task, it shouldn't require rearranging your expression!
▼
Posts: 177
Threads: 12
Joined: Jan 1970
Hi Cuppo. With a limited 4 level stack I would go after the (4 + 2) / 3 terms first.
Good luck with the 42s!
Regards,
John
Posts: 1,792
Threads: 62
Joined: Jan 2005
Cuppo 
I suppose that anyone here could give you the answer, which is to evaluate the terms in the order required for stepbystep calculation. This generally entails "working from the inside outward". Algebraic manipulation/rearrangement is not required, but sometimes reversing the order of two arguments is necessary using "x<>y".
So, the expression would be evaluated as follows:
4
ENTER
2
+
3
/
3
ENTER
2
+
6
/
+
12
*
42
x<>y

I get 8.00 as the answer.
Modern "EOS" calculators, as well as certain HP calculator models, will allow the user to enter the entire algrbraic expression lefttoright and evaluate it in one shot. (The HP42S with "Classical RPN" will not.) However, this method does not display the intermediate results, so how could the user be certain that the answer is correct?
Long live RPN!
 KS
Edited: 30 Oct 2006, 12:00 a.m.
▼
Posts: 55
Threads: 2
Joined: Jun 2006
The Intermediate results feature of the HP71b is really nice if you really want algebraic entry. I didn't really appreciate it until I sold mine. Oh well, someone else's gain.
Jonathan
Posts: 291
Threads: 43
Joined: Jun 2007
Hi Cuppo,
Notice in Karl's keystrokes that only 3 stack levels were used. 4 stacks levels is ample for virtually any problem you're likely to encounter.
Also, what don't you see in the keystroke listing?...parenthises. You don't need 'em with RPN...it's clean and efficient.
Best regards, Hal
▼
Posts: 515
Threads: 41
Joined: Feb 2006
With RPN, one should approach the problem similar to doing it by hand. The inner part should be solved first.
Posts: 11
Threads: 0
Joined: Jan 1970
Three stack levels is all you ever really need. The forth is nice for really complicated problems (and in the case of classic HP RPN the 4th Tregister serves as a repeating constant useful in some calculations). Karl's solution is fairly typical of anyone that understands RPN notation  it's the intermediate results as stored on the stack that makes RPN so clean and efficient. Sure, if you have a deeper stack you could enter the equation in from left to right, but it's not the "RPN way" and really undoes some of what makes RPN so clean. Generally, no RPN user ever laments the short stack. Once you really understand the nature of RPN the use of the stack to store an intermediate result becomes second nature. The process becomes very mechanical  and is even less prone to errors of trying to transform the equation from lefttoright to fit the stack model. Since you're seeing the intermediate results you always get a sense that your computation is going correctly  and, occasionally, the intermediate results are more than simply interesting  you can always STO them off to a storage register for use in later parts of future computations.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hello, Dave 
Quote:
Three stack levels is all you ever really need. The fourth is nice for really complicated problems...
I agree with everything else you stated (thank you), but I'd say that a 4level stack is about ideal, whereas three can be quite constraining  even for fairlyroutine problems.
In the late 1970's, National Semiconductor made some cheaper RPN calc's with threelevel stacks. They fell by the wayside...
 KS
Posts: 2,448
Threads: 90
Joined: Jul 2005
Quote:
During an exam, the number crunching part should be a nobrainer task, it shouldn't require rearranging your expression!
I am afraid I completely disagree. Any "nobrainer" moments are a bad idea during an exam:)
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
Any "nobrainer" moments are a bad idea during an exam:)
Amen to that! "Nobrainer" has got to be the the stupidest idiomatic expression ever devised. How it ever gained acceptance, I have no idea.
For those who didn't learn Americanstyle English: A "nobrainer" is intended to describe a decision so easy and intuitively obvious, that the correct choice requires no brains or thought to make. Unfortunately, the words convey just the opposite...
 KS
▼
Posts: 4,027
Threads: 172
Joined: Aug 2005
Hi Karl, guys;
I was so (sadly) surprised with the "no brainer" reference to the number crunching (needed) activities that I felt no motivation to post a possible solution.
My thoughts, though.
Cheers.
Luiz (Brazil)
Posts: 1,841
Threads: 54
Joined: Jul 2005
Slightly OT, but subject reminded me of some nice items I bought in Albany, OR , some years ago:
NoBrainer and also here
Other topic: You never walk alone;)
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Hard stuff! Especially the cat or cats :D
Posts: 2,309
Threads: 116
Joined: Jun 2005
Quote:
I'm looking for an answer that doesn't involve rearranging the terms.
You don't "rearrange the terms". You work the problem in exactly the same order that you would work it with pencil and paper.
With pencil and paper, what would you do first? Hint: it doesn't involve the 42.
With pencil and paper, you would start from the innermost part of the expression, which in this case would be either 4+2 or 3+2. You do the same thing in RPN. Here's a possible sequence:
4 2 + add 4 and 2
3 / divide by 3
3 2 + add 3 and 2
6 / divide by 6
+ add the two subexpressions
12 * multiply by 12
42 x<>y  subtract from 42
Notice that you only have to learn two new concepts:
 put the operator after the operands  if you want to multiply 3 by 6, you press "3 6 *". If you want to add 7 to a number already in the display, press "7 +".
 use x<>y when you need to "subtract from"  in other words, if you already have 27 in the display, and need to subtract it from 42, you press "42 x<>y ".
If you can solve problems with pencil and paper, you can solve them with RPN.
If what you want is to enter expressions as they are written on paper, rather than as you would work them, then you don't want RPN.
For anyone accustomed to actually working out the problem, RPN will make perfect sense. For people that have always solved problems with algebraic calculators, and don't know how to solve the problems without a calculator, RPN will seem strange.
Posts: 64
Threads: 4
Joined: Jan 1970
There's no solution that requires no rearranging at all. But RPN is almost always about slightly rearranging the expression anyways.
I'd probably input the expression as:
4 ENTER 2 + 3 / 3 ENTER 2 + 6 / 12 * 42 X<>Y 
but it would work as (in which only the multiplication very simply is rearranged):
42 ENTER 4 ENTER 2 + 3 / 3 ENTER 2 + 6 / 12 * 
You should consider the fact that NO calculation can be treated a nobrainer task, as you will still need to check the results, from time to time, to ensure that no user related errors happened: the calculator generally[*] provides you with a correct result, but you may well have made a mistake, like a skipped or duplicated digit during input...
[*] The calculator does not provide you with an exact result, but with an aproximation. For many cases the aproximation is a close match of the exact result, but it's not difficult to conceive a problem where this aproximation leads to a seriously wrong answer:
4/(70000003000000*(3(2/3)))
Is this actually a nobrainer?
(well, depending on how you look at the problem it could be)
The result is an exact division by zero.
Yet, a calculator, depending on the rounding modes, internal calculation base, and the number of intermediate digits may generate something quite different:
it may be infinity, which is not exactly correct (but atleast not blatantly wrong), but it may well be something like 4*10^X, with X depending on the number of digits used in the internal calculations...
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Posts: 291
Threads: 43
Joined: Jun 2007
Quote:
[*] The calculator does not provide you with an exact result, but with an aproximation. For many cases the aproximation is a close match of the exact result, but it's not difficult to conceive a problem where this aproximation leads to a seriously wrong answer:
4/(70000003000000*(3(2/3)))
Interestingly, my 33S in fraction mode hid the rounding errors until the final division, making me think it was going to give an exact solution (i.e., divide by zero error), but not so...the 400K bombshell was dropped at the last instant!
Excellent "reality check".
Best regards, Hal
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Very nice test! Calculating from inside out (or from right to left, if you prefer), I get the following results:
35v2: 4000.
33c, 41cv, Voyagers: 4.000E03
71B, 28s, Pioneers, 48GX: 4.000E05
Together with Hal's result for the 33s, it looks like HP used only two different algorithms for this type of calculation in 35 years. The last (and only) change took place 20 years ago.
Posts: 5
Threads: 1
Joined: Jan 1970
Hi,
Thanks for the help guys, i can see that i was approaching RPN the wrong way.
I still some issues with the advantages of RPN:
1. RPN is useful for errorchecking because you can see the intermediate results.
I'm not sure i can agree to this. Given simple examples with simple
numbers, yes you can mentally follow the calculations and notice errors. But if the numbers are not so clean, how are intermediate results going to help? Aren't you using a calculator because you can't do it in your head?
Also, algebraic calculators are errorprone cause you can't see the intermediate results. I can't the results, but I can see the entire expression that i entered. I can spot an error, and edit it at the character level. RPN requires stack manipulation.
RPN is stated as being very quick to learn and intuitive. But i challenge you guys, if you were given a quadratic equation to solve, how many of you can solve it faster with RPN than I can with an Algebraic calculator? If i so desired, I could store the coefficients as 'A','B',and 'C', and then i could just type out the quadratic formula as I've memorized.
I have many formulas memorized, but certainly not in reverse polish notation!
I was honestly shocked to hear you guys appalled by my "nobrainer" comment. After pages of derivation, i wouldn't mind just inputting the calculation into my algebraic 5 times over, and checking to see if the answers match. What are the chances that I'll input my calculations wrong 5 times over and make exactly the same mistake?
And unlike RPN, inputting a calculation onto an algebraic calculator is indeed a nobrainer task.
Thanks to the people that helped. Now that I understand RPN and it's advantages, I think I'm now familiar enough with RPN to know that it's not for me.
Cuppo
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
But if the numbers are not so clean, how are intermediate results going to help? Aren't you using a calculator because you can't do it in your head?
By "clean", I assume you mean "integers", or values that produce integers.
True, the user doesn't know the exact answers, but he should know what is reasonable.
Quote:
Also, algebraic calculators are errorprone cause you can't see the intermediate results. I can't the results (sic), but I can see the entire expression that i entered. I can spot an error, and edit it at the character level.
Unfortunately, the algebraic expression appearing in the display of an EOS calculator usually does not visually match the source expression on paper or computer screen, due to a short display window, lack of proper superscripting and subscripting, lack of braces and brackets to substitute for parentheses, etc.
Why, you didn't even see the error in your own verbiage! ;)
Quote:
But i challenge you guys, if you were given a quadratic equation to solve, how many of you can solve it faster with RPN than I can with an Algebraic calculator?
I'd say that most of us could, assuming that no formulae or programs had been entered beforehand...
Quote:
If i so desired, I could store the coefficients as 'A','B',and 'C', and then i could just type out the quadratic formula as I've memorized. I have many formulas memorized, but certainly not in reverse polish notation!
...
After pages of derivation, i wouldn't mind just inputting the calculation into my algebraic 5 times over, and checking to see if the answers match. What are the chances that I'll input my calculations wrong 5 times over and make exactly the same mistake?
But will your entered forumula compute and display complexconjugate roots?
For rigorous and/or repetitive processing, we can input programs. (Every RPN scientific calculator released by HewlettPackard since 1981 is programmable.) One good example of this approach is the "polynomial solutions/evaluation" RPN programs developed for the HP41 Math Pac and Advantage Pac, which will solve for both roots of a quadratic equation.
Come forth to the Church of RPN for salvation and enlightenment!
 KS
Posts: 901
Threads: 113
Joined: Jun 2007
In Message #15 above Chris Roccati wrote"
"There's no solution that requires no rearranging at all. But RPN is almost always about slightly rearranging the expression anyways."
The problem is solved exactly as written on the TI82, on the TI85 and on the Dhurabrand 828 Graphing Scientific Calculator (twenty dollars at WalMart). Those are the only true algebraics I have here at my summer home. I would be surprised if the rest of the TI graphics and the Casio scientifics do not also solve the problem as written. The hp 33s operating in algebraic mode does not solve the problem as written.
Conclusions:
1. If you want an algebraic calculator don't buy one from HP.
2. If you want an RPN calculator buy it from HP.
3. If you want information on how to use an algebraic machine don't ask an RPN guy.
4. If you want information on how to use an RPN machine don't ask an algebraic guy.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
I wrote that the hp 33s in algebraic mode could not solve the problem as written. I was wrong. I thought that it could not handle the implied multiplication betwen the 12 and the pair of opening parentheses. But, when I tried it and watched the display I saw that the 33s supplies the needed multiplication sign. So, while it can't solve the problem as written it automatically supplies the multiplication sign needed for it to solve the problem.
That is not the case with an algebraic solution on my HP28S. Then the 12(( sequence yields a syntax error when you press EVAL, and a manual insertion of a multiply between the 12 and the parentheses is required.
Posts: 4,587
Threads: 105
Joined: Jul 2005
Hi Cuppo, you raise some interesting issues. IMO I can use a calc for 2 classes of tasks overall: (A) one shot calculations I can't do in my head, (B) repeated calculations like formula evaluations.
Quote:
But if the numbers are not so clean, how are intermediate results going to help?
This is important in class (A) problems. While being taught math, you get a feeling for reasonable results. If you get/see/hear an unexpected final result and want to find its cause or origin, it is really usefull to see the results of each step, so you can understand or intervene immediately if you see something strange. RPN supports this perfectly IMHO.
Quote: Also, algebraic calculators are errorprone cause you can't see the intermediate results. I can't [see] the results, but I can see the entire expression that i entered. I can spot an error, and edit it at the character level.
Good point, referring to class (B) problems. RPN programming is an extension of manual problem solving memorizing the keys you would press to evaluate a formula. You talk about a formula editor RPN does not feature AFAIK. I'll leave this point to the experts of this forum. (IMO, at the time RPN was invented there was no idea you could ever have highres displays and operating systems in pocket devices allowing you to see an entire formula like you read it in a textbook, edit and evaluate it as you stated. RPL solved this, but that's another topic.)
Quote: RPN is stated as being very quick to learn and intuitive. But i challenge you guys, if you were given a quadratic equation to solve, how many of you can solve it faster with RPN than I can with an Algebraic calculator? If i so desired, I could store the coefficients as 'A','B',and 'C', and then i could just type out the quadratic formula as I've memorized.
I have many formulas memorized, but certainly not in reverse polish notation!
OK, this is the formula editor again. Please see above.
Hope this helps to clarify a bit.
(After posting I saw Karl's diligent post covering the same quotes. Well, now you have 2 independent views. Edited to state this, only.)
Edited: 1 Nov 2006, 3:00 a.m.
Posts: 3
Threads: 0
Joined: Jan 1970
I agree with you. There's a reason why RPN isn't terribly widespread.
I am in 100 percent agreement with you over the socalled 'advantage' of seeing working. I'd much rather see the equation I entered, to check for errors, then just a number. Why can't HP make it show both the number and the equation are shown at once?
eg if I enter 1 enter 2 +, I want to see "1+2=3".
I see nothing wrong with using the calculator to ease your workload. RPN just doesn't do that.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Well, much of this problem is generational.
I grew up using RPN. It is far more rapid and secondnature for me than "EOS" or whathaveyou. The biggest problem for years was that every calculator had its own variation on precedence. HP "algebraics" were just as problematical here as any others. In fact the 32sii equation editor is abomitable in this regard with respect to "unary minus"
On the other hand, RPN is RPN is RPN and there is no precedence, it is very clean , very direct, very simple. It meshes perfectly with the paradigms of manual computation. That is its strong point.
Today perhaps there are machines that will work with correct algebraic notation. HP48 with MK seems to be this way (except for implied mutliplication?), except that you only have parenthesis, not a choice of brackets, braces or parenthesis as you do on paper.
In 1980, there really wasn't a proper algebraic anywhere. When the SHARP pc stuff came in a few years later, that was the beginning of real algebraics. But I was already RPN at that point.
RPN uses fewer keystrokes than EOS types for simple stuff like:
taking an inverse of a number
taking the cosine
taking the sqaure root
In an eos (say hp30s), you have to go: Num (shift) ^1 ENTER
In RPN you just say Num 1/x and that's it.
Which is cleaner?
Edited: 1 Nov 2006, 9:16 a.m.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
"Well, much of this problem is generational."
It may be generational. It surely is experiential. The problem in adapting to use of the alternate methodology is not that it is better or worse but that it is different. There really aren't many true bilinguals who are equally comfortable with RPN and with AOS/EOS.
"On the other hand, RPN is RPN is RPN and there is no precedence, it is very clean , very direct, very simple. It meshes perfectly with the paradigms of manual computation. That is its strong point."
But, somehow RPN can also cause some confusion. Consider the recent thread in which RPN guys contended that 3^2 = +9. No AOS/EOS guy would ever come up with that!
"Today perhaps there are machines that will work with correct algebraic notation. HP48 with MK seems to be this way (except for implied mutliplication?), except that you only have parenthesis, not a choice of brackets, braces or parenthesis as you do on paper."
Again, my tests show that the TI82, the TI85, the Durabrand 828 and the hp33s in algebraic mode seem to work correctly. It is true that most of the early AOS machines from TI did not support implied multiplication. The lack of brackets and braces does make an EOS equation less readable than a pencil and paper version, but does not adversely affect the ability to enter the equation into the machine.
"RPN uses fewer keystrokes than EOS types for simple stuff like taking an inverse of a number ...
... In an eos (say hp30s), you have to go: Num (shift) ^1 ENTER
In RPN you just say Num 1/x and that's it."
In the hp 33s in algebraic mode you also go Num 1/x . In the TI graphics using EOS you go Num x^1 ENTER on the TI82 (three keystrokes) or num 2nd x^1 ENTER on the TI85 (four keystrokes). On all the earlier AOS machines from TI which were admittedly a mixture of prefix, postfix and whatever, you go Num 1/x .
Richard Nelson and I have exchanged numerous emails on the subject of the savings realized from fewer keystrokes with RPN. I admit that my position is based on how I used calculators. As an engineer I was primarily paid to think. Entering data into a machine was a small portion of my typical day so the saving of a few keystrokes was inconsequential. Now, if I had been employed as a keypunch operator ..." But, I wasn't.
Posts: 267
Threads: 27
Joined: Jul 2005
Cuppo wrote:
Quote:
I still some issues with the advantages of RPN
I don't know if you've had the opportunity to read this electronic version of an old HP
brochure; it was posted here about a week ago by Vassilis Prevelakis in a thread titled "old HP ad in 1974 Scientific American". Good info.
Matt
▼
Posts: 515
Threads: 41
Joined: Feb 2006
Quoted "But, somehow RPN can also cause some confusion. Consider the recent thread in which RPN guys contended that 3^2 = +9. No AOS/EOS guy would ever come up with that!"
If an RPN user did the expression wrong, it's because he/she misunderstood the meaning of the expression. It's not because of RPN. To use RPN one must know what the expression means. He/she would make the same mistake if he/she did the calculation with pencil and paper. This is a positive aspect of RPN and not negative. So with AOS/EOS someone could come up with the right result without knowing how what the expression really means.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
...Or (in EOS) come up with the wrong expression without knowingdepending on how the "unary minus" is handled.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Summing up: It is beneficial to have some (i.e. >>0 ) basic understanding of math and the operation of your calculator/computer while working with it. Else, you may produce false results and won't even perceive it, regardless of the system you use. So, you may leave your brain on.
I hope this is a sum everybody here can accept.
Posts: 135
Threads: 13
Joined: Jan 1970
RPN is also great when you have chain calculations to do. With RPN I also think you get a better feel for the calculation since you start the evaluation from inside the parenthesis and work outwards. It is less of a black box operation since you see intermediate results. For a complex calc I don't know precisely what each intermediate result should be, but I usually have a rough idea.
I too was shocked at the nobrainer comment. I agree with the other poster who said that nobrainer moments on a test are not a good idea, but they are even worse in the "real world" when the results of your calculation may be used to design something.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
The user can see most of the intermediate results when using the old A.O.S. machines and when using the hp 33s in algebraic mode. For the problem at the beginning of this thread:
Keystrokes Display
42 42
 42
12 12
x 12
( 12
( 12
4 4
+ 4
2 2
) 6 (4+2)
/ 6
3 3
+ 2 (4+2)/3
( 2
3 3
+ 3
2 2
) 5 (3+2)
/ 5
6 6
) 2.833333 ((4+2)/3 + (3+2)/6)
= 8
where those keystrokes are for a TI30, TI59, etc. For the hp 33s the multiply in front of the pair of opening parentheses does not have to be entered. The machine does it for the user. If you think about this for a minute you will realze that the problem has been solved from the inside out because that is the way it must be done. The big difference relative to RPN is that (1) the user doesn't have to search the equation for the starting point and (2) decide entry by entry which to perform next. The machine does all that automatically.
Equation Operating System (EOS) machines are another matter. Intermediate results are not available. The big advantages of EOS are being able to see and review the entire equation entry and being able to recall the equation entry and change parts of the entered equation.
▼
Posts: 5
Threads: 1
Joined: Jan 1970
I think the following problem example highlights pretty clearly some disadvantages of 4level RPN:
[(3+1)(4+3)+(2+6)(4+6)] / [(2+3)(2+1) + (3+5)(4+2)] = ?
This problem is not possible using a 4level stack without using STORE.
On the other hand: on my $10 casio, it's about a 7 second punch.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Memory has been a part of RPN since day one. Use it.
It is an artificial argument to say that the 4 level stack won't work without memory. Using memory is part of the system.
Most equation entry systems have a buffer limit anyway. At some point, you have to use memory on them, because the argument is larger than the maximum character limit. So it's no different in that respect.
I like EOS and RPN and I use both. I frequently use a 27s which has both EOS and traditional scientific pre/postfix. I use a 32sii for most simple stuff. RPN is great for thinking with numbers.
You might actually appreciate the RPL world. In RPL, you have RPN entry for manual work, but you have algebraic objects. All objects can be handled on a stack (infinite depth) or handled through variables (user declared, rather than machine allocated registers). So you can input with EOS, save or duplicate it, evaluate it, chain the results to other items on the stack etc. Pretty neat really. Perhaps the Holy Grail. Just that I am usually perfectly happy with the olderfashioned. (I like fountain pens too.)
Edited: 2 Nov 2006, 12:15 p.m.
▼
Posts: 20
Threads: 2
Joined: Jan 1970
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
I'm not sure he's a Troll. Not enough warts.
Posts: 64
Threads: 4
Joined: Jan 1970
Quote:
[(3+1)(4+3)+(2+6)(4+6)] / [(2+3)(2+1) + (3+5)(4+2)] = ?
This problem is not possible using a 4level stack without using STORE.
That's why even the HP35 (1972) had one storage register.
▼
Posts: 515
Threads: 41
Joined: Feb 2006
Cuppo you win! You can exchange that used and old 42S with some of us for a brand new top of the line EOS calculator. Any brand or model your choice!
▼
Posts: 5
Threads: 1
Joined: Jan 1970
After using the HP 42S for about 2 weeks, I've decided that it's not worth my time or effort to learn RPN. Consequentially, I will be selling it on ebay in the near future for $250 CAD. I believe this is significantly below market price, and I am posting it here first as a token of appreciation for your help and opinions.
If your interested, i would suggest to keep a close watch on ebay.
Thank you especially to John Smitherman, Karl Schneider, Jonathan Eisch, Hal Bitton, Dia C. Tran, Dave Bernazzani, Eric Smith, Chris Roccati, Palmer O. Hanson, Jr., Walter B, "someone", Matt Kernal, and e.young, for your responses.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
▼
Posts: 5
Threads: 1
Joined: Jan 1970
My apologies. Thanks to bill platt also for his help.
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
I think the following problem example highlights pretty clearly some disadvantages of 4level RPN:
[(3+1)(4+3)+(2+6)(4+6)] / [(2+3)(2+1) + (3+5)(4+2)] = ?
This problem is not possible using a 4level stack without using STORE.
Aha, another exercise in arithmetic that requires at least five levels to accommodate the final operand and all four previous partial calculations! (It's been done before to prove the same point.)
This expression can be calculated on an HP42S without using STO. The approach utilizes just a bit of algebra, along with the following features, of which only the HP42S  among "classic RPN" models  offers all three:
LASTx register
direct stack access
RCL arithmetic
(Only the HP41 also offers direct stack access, but it lacks RCL arithmetic; only the HP15C also offers RCL arithmetic, but it lacks direct stack access.)
3 ENTER 1 +
4 ENTER 3 +
*
2 ENTER 6 +
4 ENTER 6 +
*
+
2 ENTER 3 +
2 ENTER 1 +
*
3 ENTER 5 +
4 x<>y *
2 RCL* ST L (RCL * . "ST L")
+
+
/
Answer is 108/63 = 12/7 = 1.71429
Of course, this could be considered "cheating" in a way, because LASTx  which was provided for correction of errors  can be exploited as a "fifth stack register", and also because some algebra was used.
The RPLbased models (HP28/48/49/50) have dynamicdepth stacks, and can accomodate calculations of this form. However, the stackmanipulation RPL commands for variablelength stacks are numerous and unintuitive.
A fourelement stack offered a perfect compromise of practicality and efficiency in the early days. My design of a new RPN calculator would include a fixed stack of userdefinable depth (e.g., "STKD" command). Four would be the default; nine (STKD 9) or 19 elements (STKD .9) would be the maximum.
 KS
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
Of course, with an RPL model, you can key it into the command
line editor as
'((3+1)*(4+3)+(2+6)*(4+6))/((2+3)*(2+1)+(3+5)*(4+2))' or, making
the order of operations explicit with extra parantheses,
'(((3+1)*(4+3))+((2+6)*(4+6)))/(((2+3)*(2+1))+((3+5)*(4+2)))'. Note
the explicit multiplications and the use of nested parentheses
instead of using "square brackets". Pressing ENTER puts the
expression on the stack as an "algebraic object". In approximate
mode, pressing EVAL returns 1.71428571429; in exact mode (49
series) pressing EVAL returns '12/7', and you have to do an \>NUM
command to get it to return 1.71428571429.
Algebraic objects can be useful when you already have the
algebraic expession written out in front of you, such as copying
it from a handbook or text book. Even so, "translating" it to an
RPL sequence is easy enough, and the only limitation on stack
depth with an RPL model is available memory. Although translation
to an RPN sequence is usually described as "working from the
inside out", much as working out the problem with pencil and
paper, with the indefinite stack depth of the RPL models, you can
do it similar to "left to right" except moving the operators to
after their arguments, for example:
3 1 + 4 3 + * 2 6 + 4 6 + * + 2 3 + 2 1 + * 3 5 + 4 2 + * + /
Note that you can just type all of the above into the command line editor (perhaps using Newlines in place of some of the spaces) and press ENTER to evaluate it, or you can press the ENTER key after each number.
Regards, James
Edited: 3 Nov 2006, 2:11 a.m.
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
PS:
I find the RPL stack manipulation commands to be perfectly intuitive, but for this problem, why would I be using them anyway?
Regards, James
Posts: 35
Threads: 1
Joined: Jan 2007
Actually, with my RPN machine, I can do the calculation in 7 seconds as well, even if I use a STO, which I don't perceive to be a real issue (registers are designed for that!).
What disturbs me more with RPN machine is not the limited stack, but the fact that you need to bear in mind how full you stack is to avoid tossing the last element out and introducing a duplicate of the last element instead (sometimes hard to detect!)
If you could have all the 4 levels displayed on the screen, what wouldn't be a problem, but with a 15C, it makes use of a nonnegligible part of my concentration during calculation. I must still be low on the learning curve.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
You wrote:
"What disturbs me more with RPN machine is not the limited stack, but the fact that you need to bear in mind how full your stack is to avoid tossing the last element out and introducing a duplicate of the last element instead (sometimes hard to detect!)"
As another latecomer to the RPN scene I heartily agree. There are other oddities the user has to learn to watch for such as the disabling of stack lift after some operations and the fact that not every operation saves the contents of the x register into the LAST X register. In general, those characteristics typically aren't emphasized well enough in the front of the manuals; however, they are usually summarized in some detail somewhere near the end of the manual or in an appendix.
Those oddities aren't even mentioned when an RPN "old hand" tells you how easy it is to learn RPN because it's just like doing the math with pencil and paper. My experience is that, for any but simplistic problems, keeping track of the stack contents requires a lot of effort.
▼
Posts: 47
Threads: 4
Joined: Jan 1970
I had some difficulties at the beginning until I understood these two points:
As the stack has four registers and every binary operation uses two registers, two previous results can be stored in the stack. Easy!
Last x contains the value of X before the last binary or unary operation (except CHS, +/).
Pyjam
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Quote:
Last x contains the value of X before the last binary or unary (mathematical) operation (except CHS, +/).
That's correct, because a value altered by CHS can always be recovered by another CHS.
Stackmanipulation operations (R_down, R_up, x<>y, CLx) also do not affect the contents of LASTx. After using any of the first three operations, additional operations can recover the original stack contents. For CLx, it is assumed that the user does not want to recover the previous xregister value.
 KS
Posts: 1,041
Threads: 15
Joined: Jan 2005
I agree.
My first HP was an RPL model (28S), and I was already quite familiar with the 48SX before I ever used a "Classic RPN" machine. I thought that keeping track of a mere four stack registers would be very easy. Okay, the registers are always there; even "cleared" registers aren't removed, they're just filled with zeros, but that should be easy enough to live with. But with an RPL model, most of my attention is on the lowest stack levels, with objects farther up usually just "up there somewhere" to be dealt with later. Unless I intend to use stack manipulation commands on the higher levels, I don't usually bother to keep track of exactly how many levels there actually are. Even on the 28 series I can see at least the lowest three stack levels, and it's easy enough to view all higher levels, so I'm well aware of what's dropped down to the lower levels.
Suppose that (on a Classic RPN model) I do 1 ENTER 2 ENTER 3 ENTER 4 ENTER 5 + + +; I now have 14 (5+4+3+2) displayed in the X register, and I should have that 1 in the Y register, right? Wrong, on a classic RPN machine, the 2 that I pushed to the stack is in the Y register instead (and in Z and T registers too, for that matter), and the 1 is lost.
And what if I just do 1 ENTER 2 ENTER +? That should add 2 to 1, right? Wrong again, the second ENTER copied the 2 up to the Y register as well as leaving it in the X register, so the + added 2 to itself. It seems as if the X register is sort of an odd combination of a command line and the lowest stack level. Okay, given that the early models displayed only a single line, I suppose that this made sense at the time.
And only one or two registers are displayed; to actually view what's in the higher registers I have to roll the stack (and remember to put it back as it was).
If you've been using a Classic RPN model for years (or decades), these strange behaviours of never being able to really clear the stack, having things pushed off of the top of the stack, having the T register replicated downward, and ENTER copying the X register to the Y register may seem perfectly normal, but for those of us not very familiar with it, they can be real "Gotchas".
Okay, I realize that replicating the T register downward as objects are removed from the stack has an excellent design purpose and can be extremely useful given the limitations of Classic RPN machines, but I think that I'll stick with the easy to use, very intuitive RPL models. After all, what can be done with a Classic RPN model that can't be done at least as easily with an RPL model? My only serious objection with the 48 series is that they're a bit large for carrying in my pocket.
Regards, James
Edited: 4 Nov 2006, 7:18 a.m.
▼
Posts: 1,107
Threads: 159
Joined: Jan 1970
I would disagree. I believe that for many, many purposes, a 4level classic RPN environment is MUCH easier to use than the RPL environment.
At educational tradeshows and engineeringoriented events where calculators have been discussed, it is a large majority who state that the RPL machines are "too complicated for normal use".
Most calculator users who use HP machines learned on classic RPN. Think 10 years of HP41 sales that are probably several magnitudes higher than all RPL calculator sales. Think 25 years of RPN sales in the HP12c.
I believe the RPL machines corrected many of the design compromises that existed in classic RPN machines, sure. But, I believe the complexity added to all RPL machines is a doubleedged sword.
How about a discussion on why so many people still want 4level machines vs. whether the RPL machines are really easier?
Gene
▼
Posts: 1,830
Threads: 113
Joined: Aug 2005
Having participated in a long, long thread on these topics, I can perhaps shorten this one by reporting the consensus of that one: which system seems easier depends very much on which you learned first. There's no doubt that RPL is more complicated than RPN, but those that learned the former first get frustrated by what they perceive as the limitations on the latter. These include a shallow stack and less consistent postfix syntax. Those of us that learned RPN first tend to be put off by the necessity of tracking an unlimiteddepth stack, and by the sheer number of additional functions, few of which are easily "discoverable" from the keyboard.
I don't count named variables as items the RPL crowd misses, or that the RPN crowd is put off by. That's because the hardcore RPL folks seldom use the things in programs, relying instead on the stack, usually well more than four levels of which are routinely used to store anonymous data. It is in fact marginally less efficient to use named parameters in RPL, which is a pity, since the gain in programmer efficiency can be substantial, at least to judge by this programmer's experience.
But there is a certain joy in writing in that terse, lispian/forthish style. Once you get used to it, and for me that took quite a long while, RPL can seem very natural. A big part of that is just memorizing the stack behavior of that subset of RPL you tend to use frequently. Once your diving into the AUR stops happening at every other command, the language starts to feel very expressive, and even "normal."
I still get more satisfaction out of coding in RPN, however. This has to do with the way my brain was wired by my first HP41C. I learned to program on the device before I ever touched a larger computer. For years I would recode tough problems in FOCAL in order to understand them better. (I continued to do this even after my original machine was stolen  on paper.) I still have an easier time reading FOCAL than RPL. I believe that this is not due alone to the fact that RPL programs tend to be larger and more complex. I think it's because FOCAL is my "native" calculator language. Fortunately, I'm not one to insist that immigrants go back where they came from. I see RPL as a welcome addition to the body of computer languages. I enjoy reading discussions of how it differs from RPN, too. But I don't think that one or the other is easier in absolute terms.
Regards, Howard
▼
Posts: 1,041
Threads: 15
Joined: Jan 2005
I agree with at least most of what you wrote, Howard, and have no
serious disagreement with any of it.
I certainly didn't intend to trigger any flame war, and I
certainly don't expect to change the opinion of anyone who has a
strong opinion on which of Classic RPN or RPL is "better".
Actually, before I ever had my hands on an HP calculator, my main
"calculator" for use with any more than a trivial program was a
Sharp EL5520 Scientific Computer. This has a CAL mode for use as
an ordinary calculator, and a BASIC mode with separate "submodes"
for writing and running programs in its version of BASIC. I'd been
using it for maybe a year or so, and I think that I was reasonably
proficient both in using it as a calculator and at writing
programs for it to run.
But the first time that I played with a 28S at a store display, I
think that it took me less than five minutes to realize that it
was much easier to use than any other calculator that I'd ever
tried, and was certainly a "must have" item. So it's not
necessarily a matter of whatever one learned to use first is
always easiest.
But in deciding between Classic RPN and RPL models, both being
types of RPN calculators, the choice isn't so easy, and which type
one learned first does indeed seem to be a major reason for
preferring one over the other.
I probably could learn to use Classic RPN very well,
but why bother? Similarly, I have no doubt that the regulars on
this forum who prefer Classic RPN could learn to use RPL very well
if they really wanted to, but as long as Classic RPN does
everything that they ask of it, what motivation would they have
for learning to use an RPL model?
Regarding named variables, it's certainly true that I very rarely
call a global variable from a program, and I wouldn't want to do
it in a program that I was posting as an example for others (if
for no other reason, because then I'd pretty well have to post the
contents of the called variable as well), unless the purpose of
the example involved calling a global variable from within a
program.
If a program uses a subprogram, I normally prefer to include it
within the program itself, rather than storing it in a separate
global variable to be called. But suppose that a value is to be
stored for future use when the program is next run? In that case,
a local variable wouldn't work. For such cases, I'd recommend
using a subdirectory (or branch) for the program and whatever
global variables it needs.
I do frequently use named local variables for storing values or
subprograms within a program, but for these I normally use
1character names; using a register number instead would be pretty
much a nonissue.
Certainly I use named global variables for storing programs as
well as various other objects that I want to save, and I wouldn't
want to do without them on an RPL model. But with a Classic RPN
model, how many programs would anyone have saved anyway? It does
seem to me that not having named variables for those purposes
would be pretty much another nonissue.
Yes, using local variables for temporary storage of intermediate
results is usually a little less efficient than leaving them on
the stack and using stack manipulation commands, in terms of
execution speed and program, but I think that in many cases, this
is more than made up for in terms of program development ease and
time.
Of course, if I'm responding to a "challenge" to write the fastest
or smallest program for a particular purpose, speed or size has a
higher priority.
If I were writing a program for general distribution, speed and
minimal size would have a high priority, but so far, most of what
I've posted has been in UserRPL instead of SysRPL, mostly because
that's easier for most users to understand and modify to suit
their purposes, without much risk of something terrible happening
if they happen to tweak my programs.
But with most of the programs I write, simply having a program
work correctly for what I want to use it for at the time suffices,
and development time is the next highest priority. Execution time
usually isn't long enough to be much of an issue. To be sure, a
program that executes in 1 second is a whopping five times as fast
as one that takes 5 seconds to accomplish the same thing, but if
I'm writing down results and keying in new arguments between
program runs, the slower program is "fast enough".
When is it better for me to use local variables instead of stack
manipulations? Well, that depends. What distractions am I dealing
with? How tired am I? What sort of mood am I in? Which method of
writing the program occurred to me first? Mostly, if I'm having
trouble keeping track of the stack, that's a pretty good sign that
I may well be better off using local variables.
Regards, James
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hello again, James 
Quote:
But with an RPL model, most of my attention is on the lowest stack levels, with objects farther up usually just "up there somewhere" to be dealt with later.
Oftentimes, those objects are leftover garbage from previous calculations that slows down processing and must be purged.
Quote:
(On an RPN calculator) And what if I just do 1 ENTER 2 ENTER +? That should add 2 to 1, right? Wrong again, the second ENTER copied the 2 up to the Y register as well as leaving it in the X register, so the + added 2 to itself. It seems as if the X register is sort of an odd combination of a command line and the lowest stack level. Okay, given that the early models displayed only a single line, I suppose that this made sense at the time.
Well, James, of course you know that the basic purpose of "ENTER" on an RPN calc is to terminate data entry if manual entry of another argument is to immediately follow. Arguments are already on the stack as they are keyed in. Replicating the entry and disabling stack push enables expedient doubling (number ENTER +) and squaring (number ENTER *). How about "x sin x"? (number ENTER SIN *) Expedient replication of an entered datum is valuable.
It could be argued that RPL's "ENTER" is inconsistent. When ENTER immediately follows data entry (that is, when the input buffer is not empty), the value is simply transferred from the input buffer to the actual stack. Else, ENTER replicates the value as RPN's ENTER does, except that stack push is enabled.
As for replication of the tregister in the fixeddepth 4level RPN stack, the only reasonable alternative was to fill a stack level with zero after its argument gets "popped down" by an operation. That approach could give erroneous answers just as easily as tregister replication after "stack overflow", and would not provide the convieniences of replication  e.g., an endless supply of a value for Horner's Method evaluation of polynomials, or arithmetic with a constant.
Quote:
I think that I'll stick with the easy to use, very intuitive RPL models. After all, what can be done with a Classic RPN model that can't be done at least as easily with an RPL model?
Plenty, but those discussions have been held before:
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv014.cgi?read=51650#51650
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=82392#82392
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv014.cgi?read=49973#49973
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=87969#87969
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=81691#81691
In addition to these threads from several years ago, there were several in which Valentin Albillo engaged you in lengthy discussions about these issues.
Regards,
 KS
Edited: 4 Nov 2006, 10:56 p.m.
▼
Posts: 1,107
Threads: 159
Joined: Jan 1970
Karl wrote: "How about "x sin x"? (number ENTER SIN *)"
Gene: Quite right in RPN. In RPL, due to the "inconsistent" behavior of ENTER, it requires the following keys:
number ENTER ENTER SIN *
An extra ENTER is required to terminate digit entry, then ENTER again to DUP the argument to level 2 of the stack.
No system is perfect and I'm sure we're very biased by the architecture we first learned on, regardless of whether we have subsequently learned a differerent method.
I think this is a good poll question for HHC2007:
When you have to do some "basic number crunching", which would you pick up to do the task, assuming each had the appropriate math functions:
RPNbased calculator
RPLbased calculator?
I'll try to ask that next year.
Gene
Posts: 1,041
Threads: 15
Joined: Jan 2005
And hello again to you Karl,
First off, I think that you're reading way too much into my post.
I'm not saying that Classic RPN is poorly designed; indeed, it's
it's a very good design, particularly considering what was
available to work with at the time.
What I am saying is that for someone accustomed to RPL models,
Classic RPN has some differences that are easy to forget. After
all, they're both RPN, and do have a lot in common; much more
than, for example, an RPN model and an algebraic or BASIC model.
Quote:
Oftentimes, those objects are leftover garbage from previous
calculations that slows down processing and must be purged.
Umm, maybe with your calculators, but with my calculators, I
always discard any unneeded objects from the stack before starting
a new calculation. In most cases, that means clearing the stack if
it's not already empty.
Quote:
Well, James, of course you know that the basic purpose of "ENTER"
on an RPN calc is to terminate data entry if manual entry of
another argument is to immediately follow.
Of course. My point is that it's easy to forget that Classic RPN
has some important differences from RPL.
Quote:
Arguments are already on the stack as they are keyed
in.
Exactly my point! Classic RPN doesn't have a separate command
line.
Quote:
Replicating the entry and disabling stack push enables
expedient doubling (number ENTER +) and squaring (number ENTER *).
How about "x sin x"? (number ENTER SIN *) Expedient replication
of an entered datum is valuable.
Quite so, and no doubt that's why with RPL models, when in the
standard stack environment (no command line or other "special
environment" active), the ENTER key is a shortcut for the DUP
command.
Yes, for your examples above, an RPL model requires two presses of
the ENTER key, one to do the ENTER, immediately followed by
another for the DUP command. Is that so difficult? I already have
my finger on the ENTER key, so doing a double press instead of a
single press is very easy. What may be difficult is remembering
that RPL and Classic RPN do have such differences.
Quote:
It could be argued that RPL's "ENTER" is inconsistent.
It's certainly true that RPL's ENTER key is frequently used for
purposes other than ENTER. Then too, many "immediate entry" keys
can do an "implicit ENTER".
Quote:
When ENTER immediately follows data entry (that is, when the input
buffer is not empty), the value is simply transferred from the
input buffer to the actual stack. Else, ENTER replicates the value
as RPN's ENTER does, except that stack push is enabled.
RPL's ENTER does quite a lot, some of it optionally depending on
such matters as whether the last stack and last command line save
modes are enabled, whether vectored ENTER is in effect, whether
there's a syntax error, and so on. Bill Wickes uses about three
pages for "ENTER in Detail", which you could read in
Insights.
Yes, if the only thing in the command line is the source for a
single data class object, then (normally) it looks to the user as
if all that happened was that the command line was closed,
returning to the standard stack environment, with the object moved
from the command line to stack level 1.
But suppose that my command line contains more than one data class
object? In that case, ENTER ends up placing the last one on level
1, with each preceding one on the next level up, just as if I'd
pressed ENTER after each one.
Or suppose that my command line looks like:
1 2 + 3  4 * 5 /
ENTER, among other things, parses the command line and combines
the objects into a single secondary (SysRPL program), which is
executed before updating the display. So for the above, the first
thing that the user sees different is the standard stack display,
with the result, 0, in level 1.
One way of looking at it is that the command line is a program to
be executed by ENTER (assuming valid syntax); it can even include
program structures. One could edit out the opening and closing
program delimiters of any UserRPL program, in which case ENTER
ends up "executing" the command line as if it were a program
(which indeed it as before the ENTER operation is complete).
Or one could view a program as a command line "quoted" with
program delimiters for deferred execution, so that it can be
placed on the stack and optionally executed, stored in a variable,
or anything else that can be done with an object on the stack.
Other special environments, such as the matrix writer, equation
writer, various input forms, and so on, each have their own
particular definitions for what a press of the ENTER key does in a
particular circumstance. Typically, it means "Okay, go ahead and
process this", or simply "Yes" or "Acknowledged". None of these
would apply to the standard stack environment, and the developers
very wisely chose to make it a shortcut to the DUP command there.
Quote:
As for replication of the tregister in the fixeddepth 4level
RPN stack, the only reasonable alternative was to fill a stack
level with zero after its argument gets "popped down" by an
operation. That approach could give erroneous answers just as
easily as tregister replication after "stack overflow", and would
not provide the convieniences of replication  e.g., an endless
supply of a value for Horner's Method evaluation of polynomials,
or arithmetic with a constant.
Quite so. It's the stack overflow that causes a problem, not the
replication of the tregister, which I believe I acknowledged was
a very good design feature.
Even so, the possibility of a stack overflow is one of those
things that can be a problem for those not accustomed to it.
I suppose that maybe they could've designed it to error out in
case of a stack overflow, but that would have the disadvantage of
requiring the user to clear the stack frequently, and with a
Classic RPN model, it's not so obvious what's in the stack
registers when the user is about to begin a new calculation. Also,
how would they detect a stack overflow? A user might intentionally
have a 0 in the tregister, in which case trying to lift the stack
should trigger a stack overflow error, just as when anything else
is in the tregister. I think that they made the best decision;
make the limitations clear, and depend on the user to stay within
them.
Quote:
Quote:
I think that I'll stick with the easy to use, very intuitive RPL
models. After all, what can be done with a Classic RPN model that
can't be done at least as easily with an RPL model?
Plenty, but those discussions have been held before:
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv014.cgi?read=51650#51650
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=82392#82392
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv014.cgi?read=49973#49973
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=87969#87969
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=81691#81691
Come on now, my memory's not that bad. I also remember that after
those discussions, I was even more firmly convinced that RPL is
easier to use and more intuitive than Classic RPN. I've yet to see
anything that would tend to change that opinion. I have no doubt
that for someone not accustomed to RPL, it might seem difficult to
use and counterintuitive, or that some will refuse to see any
advantages of RPL, no matter how apparent.
Quote:
In addition to these threads from several years ago, there were
several in which Valentin Albillo engaged you in lengthy
discussions about these issues.
Well now, it seem to me that comparing the 71B's BASIC and RPL is
much like comparing apples and oranges; they're certainly
"different", but I wouldn't care to say that either one is
"better". Certainly for me, not being familiar with the 71B, RPL
is better, and my impression is that for Valentin, the 71B's BASIC
is better.
Regards, James
Edited: 6 Nov 2006, 5:40 a.m.
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi James,
Quote: Come on now, my memory's not that bad. I also remember that after those discussions, I was even more firmly convinced that RPL is easier to use and more intuitive than Classic RPN.
You see, it really is merely a matter of what you are most familiar with. I think the RPN machines are more logical. I never touched an RPL until 1998, and never had one until 2002.
