The Museum of HP Calculators

HP Forum Archive 16

 How do i input this using RPN?Message #1 Posted by Cuppo on 29 Oct 2006, 10:59 p.m. 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 4-level 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 no-brainer task, it shouldn't require re-arranging your expression!

 Re: How do i input this using RPN?Message #2 Posted by John Smitherman on 29 Oct 2006, 11:07 p.m.,in response to message #1 by Cuppo 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

 Re: How do i input this using RPN?Message #3 Posted by Karl Schneider on 29 Oct 2006, 11:41 p.m.,in response to message #1 by Cuppo Cuppo -- I suppose that anyone here could give you the answer, which is to evaluate the terms in the order required for step-by-step 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 left-to-right and evaluate it in one shot. (The HP-42S 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.

 Re: How do i input this using RPN?Message #4 Posted by Jonathan Eisch on 30 Oct 2006, 1:04 a.m.,in response to message #3 by Karl Schneider The Intermediate results feature of the HP-71b 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

 Re: How do i input this using RPN?Message #5 Posted by Hal Bitton on 30 Oct 2006, 1:42 a.m.,in response to message #1 by Cuppo 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

 Re: How do i input this using RPN?Message #6 Posted by Dia C. Tran on 30 Oct 2006, 8:21 a.m.,in response to message #5 by Hal Bitton With RPN, one should approach the problem similar to doing it by hand. The inner part should be solved first.

 Re: How do i input this using RPN?Message #7 Posted by Dave Bernazzani on 30 Oct 2006, 2:31 p.m.,in response to message #5 by Hal Bitton 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 T-register 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 left-to-right 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.

 Re: How do i input this using RPN?Message #8 Posted by Karl Schneider on 31 Oct 2006, 12:27 a.m.,in response to message #7 by Dave Bernazzani 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 4-level stack is about ideal, whereas three can be quite constraining -- even for fairly-routine problems. In the late 1970's, National Semiconductor made some cheaper RPN calc's with three-level stacks. They fell by the wayside... -- KS

 Re: How do i input this using RPN?Message #9 Posted by bill platt on 30 Oct 2006, 3:28 p.m.,in response to message #1 by Cuppo Quote: During an exam, the number crunching part should be a no-brainer task, it shouldn't require re-arranging your expression! I am afraid I completely disagree. Any "no-brainer" moments are a bad idea during an exam:-)

 "No-brainer"Message #10 Posted by Karl Schneider on 31 Oct 2006, 12:33 a.m.,in response to message #9 by bill platt Quote: Any "no-brainer" moments are a bad idea during an exam:-) Amen to that! "No-brainer" 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 American-style English: A "no-brainer" 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

 Re: "No-brainer"Message #11 Posted by Vieira, Luiz C. (Brazil) on 31 Oct 2006, 12:45 a.m.,in response to message #10 by Karl Schneider 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)

 Re: "No-brainer"Message #12 Posted by Raymond Del Tondo on 31 Oct 2006, 4:59 a.m.,in response to message #10 by Karl Schneider Slightly OT, but subject reminded me of some nice items I bought in Albany, OR , some years ago: No-Brainer and also here Other topic: You never walk alone;-)

 Re: "No-brainer"Message #13 Posted by Walter B on 31 Oct 2006, 4:36 p.m.,in response to message #12 by Raymond Del Tondo Hard stuff! Especially the cat or cats :-D

 Re: How do i input this using RPN?Message #14 Posted by Eric Smith on 30 Oct 2006, 5:32 p.m.,in response to message #1 by Cuppo 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.

 Re: How do i input this using RPN?Message #15 Posted by Chris Roccati on 31 Oct 2006, 8:46 a.m.,in response to message #1 by Cuppo 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 no-brainer 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/(7000000-3000000*(3-(2/3)))` Is this actually a no-brainer? (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...

 Re: How do i input this using RPN?Message #16 Posted by bill platt on 31 Oct 2006, 9:31 a.m.,in response to message #15 by Chris Roccati Excellent example.

 Re: How do i input this using RPN?Message #17 Posted by Hal Bitton on 31 Oct 2006, 11:01 a.m.,in response to message #15 by Chris Roccati 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/(7000000-3000000*(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

 Re: How do i input this using RPN?Message #18 Posted by Walter B on 31 Oct 2006, 5:28 p.m.,in response to message #17 by Hal Bitton 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.

 Re: How do i input this using RPN?Message #19 Posted by Cuppo on 31 Oct 2006, 5:47 p.m.,in response to message #17 by Hal Bitton 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 error-checking 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 error-prone 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 "no-brainer" 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 no-brainer 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

 Re: How do i input this using RPN?Message #21 Posted by Palmer O. Hanson, Jr. on 1 Nov 2006, 1:42 a.m.,in response to message #19 by Cuppo 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 TI-82, on the TI-85 and on the Dhurabrand 828 Graphing Scientific Calculator (twenty dollars at Wal-Mart). 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 H-P. 2. If you want an RPN calculator buy it from H-P. 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.

 Mea CulpaMessage #22 Posted by Palmer O. Hanson, Jr. on 1 Nov 2006, 3:25 a.m.,in response to message #21 by Palmer O. Hanson, Jr. 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 HP-28S. 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.

 Different applications (was: How do i input this using RPN?)Message #23 Posted by Walter B on 1 Nov 2006, 2:50 a.m.,in response to message #19 by Cuppo 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 error-prone 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 high-res 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.

 Re: How do i input this using RPN?Message #24 Posted by someone on 1 Nov 2006, 3:24 a.m.,in response to message #19 by Cuppo I agree with you. There's a reason why RPN isn't terribly widespread. I am in 100 percent agreement with you over the so-called '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.

 Re: How do i input this using RPN?Message #25 Posted by bill platt on 1 Nov 2006, 9:15 a.m.,in response to message #24 by someone Well, much of this problem is generational. I grew up using RPN. It is far more rapid and second-nature 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.

 Re: How do i input this using RPN?Message #26 Posted by Palmer O. Hanson, Jr. on 1 Nov 2006, 10:34 a.m.,in response to message #25 by bill platt "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 TI-82, the TI-85, 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 TI-82 (three keystrokes) or num 2nd x^-1 ENTER on the TI-85 (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 e-mails 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.

 Re: How do i input this using RPN?Message #27 Posted by Matt Kernal (US) on 1 Nov 2006, 11:16 a.m.,in response to message #19 by Cuppo 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

 Re: How do i input this using RPN?Message #28 Posted by Dia C. Tran on 1 Nov 2006, 2:39 p.m.,in response to message #27 by Matt Kernal (US) 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.

 Re: How do i input this using RPN?Message #29 Posted by bill platt on 1 Nov 2006, 2:45 p.m.,in response to message #28 by Dia C. Tran ...Or (in EOS) come up with the wrong expression without knowing--depending on how the "unary minus" is handled.

 Re: How do i input this using RPN?Message #30 Posted by Walter B on 1 Nov 2006, 4:29 p.m.,in response to message #29 by bill platt 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.

 Re: How do i input this using RPN?Message #31 Posted by e.young on 1 Nov 2006, 4:31 p.m.,in response to message #19 by Cuppo 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 no-brainer comment. I agree with the other poster who said that no-brainer 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.

 Seeing intermediate results with algebraic machinesMessage #32 Posted by Palmer O. Hanson, Jr. on 2 Nov 2006, 2:35 a.m.,in response to message #31 by e.young 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 TI-30, TI-59, 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.

 Re: Seeing intermediate results with algebraic machinesMessage #33 Posted by Cuppo on 2 Nov 2006, 11:57 a.m.,in response to message #32 by Palmer O. Hanson, Jr. I think the following problem example highlights pretty clearly some disadvantages of 4-level RPN: [(3+1)(4+3)+(2+6)(4+6)] / [(2+3)(2+1) + (3+5)(4+2)] = ? This problem is not possible using a 4-level stack without using STORE. On the other hand: on my \$10 casio, it's about a 7 second punch.

 Re: Seeing intermediate results with algebraic machinesMessage #34 Posted by bill platt on 2 Nov 2006, 12:07 p.m.,in response to message #33 by Cuppo 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 older-fashioned. (I like fountain pens too.) Edited: 2 Nov 2006, 12:15 p.m.

 Re: Seeing intermediate results with algebraic machinesMessage #35 Posted by Tom F on 2 Nov 2006, 12:26 p.m.,in response to message #34 by bill platt Stop feeding the troll.

 Re: Seeing intermediate results with algebraic machinesMessage #36 Posted by bill platt on 2 Nov 2006, 12:33 p.m.,in response to message #35 by Tom F I'm not sure he's a Troll. Not enough warts.

 Re: Seeing intermediate results with algebraic machinesMessage #37 Posted by Chris Roccati on 2 Nov 2006, 12:29 p.m.,in response to message #33 by Cuppo Quote: [(3+1)(4+3)+(2+6)(4+6)] / [(2+3)(2+1) + (3+5)(4+2)] = ? This problem is not possible using a 4-level stack without using STORE. That's why even the HP-35 (1972) had one storage register.

 Re: Seeing intermediate results with algebraic machinesMessage #38 Posted by Dia C. Tran on 2 Nov 2006, 12:36 p.m.,in response to message #37 by Chris Roccati 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!

 Re: Seeing intermediate results with algebraic machinesMessage #39 Posted by Cuppo on 2 Nov 2006, 4:43 p.m.,in response to message #38 by Dia C. Tran 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.

 Re: Seeing intermediate results with algebraic machinesMessage #40 Posted by bill platt on 2 Nov 2006, 5:14 p.m.,in response to message #39 by Cuppo Hey! what about me? ;-)

 Re: Seeing intermediate results with algebraic machinesMessage #41 Posted by Cuppo on 2 Nov 2006, 5:22 p.m.,in response to message #40 by bill platt My apologies. Thanks to bill platt also for his help.

 *Can* be done on HP-42S w/o STO...Message #42 Posted by Karl Schneider on 2 Nov 2006, 11:18 p.m.,in response to message #33 by Cuppo Quote: I think the following problem example highlights pretty clearly some disadvantages of 4-level RPN: [(3+1)(4+3)+(2+6)(4+6)] / [(2+3)(2+1) + (3+5)(4+2)] = ? This problem is not possible using a 4-level 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 HP-42S without using STO. The approach utilizes just a bit of algebra, along with the following features, of which only the HP-42S -- among "classic RPN" models -- offers all three: LASTx register direct stack access RCL arithmetic (Only the HP-41 also offers direct stack access, but it lacks RCL arithmetic; only the HP-15C 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 RPL-based models (HP-28/48/49/50) have dynamic-depth stacks, and can accomodate calculations of this form. However, the stack-manipulation RPL commands for variable-length stacks are numerous and unintuitive. A four-element 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 user-definable depth (e.g., "STKD" command). Four would be the default; nine (STKD 9) or 19 elements (STKD .9) would be the maximum. -- KS

 Re: *Can* be done on HP-42S w/o STO...Message #43 Posted by James M. Prange (Michigan) on 3 Nov 2006, 2:03 a.m.,in response to message #42 by Karl Schneider 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.

 Re: *Can* be done on HP-42S w/o STO...Message #44 Posted by James M. Prange (Michigan) on 3 Nov 2006, 2:18 a.m.,in response to message #43 by James M. Prange (Michigan) 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

 Re: Seeing intermediate results with algebraic machinesMessage #45 Posted by Bruno Ferard on 3 Nov 2006, 4:41 p.m.,in response to message #33 by Cuppo 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 non-negligible part of my concentration during calculation. I must still be low on the learning curve.

 The Response of the t RegisterMessage #46 Posted by Palmer O. Hanson, Jr. on 3 Nov 2006, 9:46 p.m.,in response to message #45 by Bruno Ferard 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.

 Re: The Response of the t RegisterMessage #47 Posted by Patrick Jamet on 4 Nov 2006, 4:27 a.m.,in response to message #46 by Palmer O. Hanson, Jr. 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

 Philosophy of LASTxMessage #48 Posted by Karl Schneider on 4 Nov 2006, 3:12 p.m.,in response to message #47 by Patrick Jamet 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. Stack-manipulation 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 x-register value. -- KS

 Re: Seeing intermediate results with algebraic machinesMessage #49 Posted by James M. Prange (Michigan) on 4 Nov 2006, 6:38 a.m.,in response to message #45 by Bruno Ferard 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.

 Which is easier to use? RPL vs. RPNMessage #50 Posted by Gene on 4 Nov 2006, 3:14 p.m.,in response to message #49 by James M. Prange (Michigan) I would disagree. I believe that for many, many purposes, a 4-level classic RPN environment is MUCH easier to use than the RPL environment. At educational trade-shows and engineering-oriented 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 double-edged sword. How about a discussion on why so many people still want 4-level machines vs. whether the RPL machines are really easier? Gene

 Re: Which is easier to use? RPL vs. RPNMessage #51 Posted by Howard Owen on 4 Nov 2006, 6:40 p.m.,in response to message #50 by Gene 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 unlimited-depth 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 HP-41C. 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

 Re: Which is easier to use? RPL vs. RPNMessage #52 Posted by James M. Prange (Michigan) on 5 Nov 2006, 11:40 p.m.,in response to message #51 by Howard Owen 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 EL-5520 Scientific Computer. This has a CAL mode for use as an ordinary calculator, and a BASIC mode with separate "sub-modes" 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 sub-program, 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 sub-directory (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 1-character names; using a register number instead would be pretty much a non-issue. 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 non-issue. 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

 "Enter" in RPN vs. RPL & threadsMessage #53 Posted by Karl Schneider on 4 Nov 2006, 7:56 p.m.,in response to message #49 by James M. Prange (Michigan) 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 t-register in the fixed-depth 4-level 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 t-register 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: 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.

 Re: "Enter" in RPN vs. RPL & threadsMessage #54 Posted by Gene on 5 Nov 2006, 8:06 a.m.,in response to message #53 by Karl Schneider 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: RPN-based calculator RPL-based calculator? I'll try to ask that next year. Gene

 Re: "Enter" in RPN vs. RPL & threadsMessage #55 Posted by James M. Prange (Michigan) on 5 Nov 2006, 9:18 p.m.,in response to message #53 by Karl Schneider 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 t-register in the fixed-depth 4-level 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 t-register 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 t-register, 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 t-register, in which case trying to lift the stack should trigger a stack overflow error, just as when anything else is in the t-register. 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: 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 counter-intuitive, 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.

 Re: "Enter" in RPN vs. RPL & threadsMessage #56 Posted by bill platt on 6 Nov 2006, 8:26 a.m.,in response to message #55 by James M. Prange (Michigan) 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.

Go back to the main exhibit hall