How do i input this using RPN?



#48

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!


#49

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

#50

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.


#51

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

#52

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


#53

With RPN, one should approach the problem similar to doing it by hand. The inner part should be solved first.

#54

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.


#55

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

#56

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:-)


#57

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


#58

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)

#59

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;-)


#60

Hard stuff! Especially the cat or cats :-D

#61

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.

#62

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...


#63

Excellent example.

#64

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


#65

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.

#66

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


#67

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 error-prone 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 complex-conjugate roots?

For rigorous and/or repetitive processing, we can input programs. (Every RPN scientific calculator released by Hewlett-Packard since 1981 is programmable.) One good example of this approach is the "polynomial solutions/evaluation" RPN programs developed for the HP-41 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

#68

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.


#69

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.

#70

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.

#71

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.


#72

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.


#73

"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.

#74

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


#75

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.


#76

...Or (in EOS) come up with the wrong expression without knowing--depending on how the "unary minus" is handled.


#77

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.

#78

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.


#79

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.


#80

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.


#81

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.


#82

Stop feeding the troll.


#83

I'm not sure he's a Troll. Not enough warts.

#84

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.


#85

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!


#86

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.


#87

Hey! what about me? ;-)


#88

My apologies. Thanks to bill platt also for his help.

#89

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



  • #90

    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.


    #91

    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

    #92

    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.


    #93

    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.


    #94

    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


    #95

    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

    #96

    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.


    #97

    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


    #98

    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


    #99

    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

    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:

    http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=51650#51650

    http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=82392#82392

    http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=49973#49973

    http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=87969#87969

    http://www.hpmuseum.org/cgi-sys/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.


    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

    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:

    http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=51650#51650

    http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=82392#82392

    http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=49973#49973

    http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv015.cgi?read=87969#87969

    http://www.hpmuseum.org/cgi-sys/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 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.


    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.


    Possibly Related Threads...
    Thread Author Replies Views Last Post
      INPUT for HP Prime Eddie W. Shore 3 1,007 11-17-2013, 04:46 PM
    Last Post: Michael de Estrada
      HP Prime Tutorial #4 is up (CASE/CHOOSE/INPUT) Eddie W. Shore 1 798 11-15-2013, 07:32 AM
    Last Post: Davi Ribeiro de Oliveira
      HP Prime Programming Tutorial #3: WHILE, INPUT, KILL, REPEAT, GETKEY Eddie W. Shore 5 1,439 11-07-2013, 12:25 AM
    Last Post: Han
      [PRIME] RPN: another attempt at returning more than one value to the RPN stack Marcus von Cube, Germany 5 1,492 11-05-2013, 02:44 AM
    Last Post: Marcus von Cube, Germany
      minor visual bug in INPUT Han 0 600 10-03-2013, 01:13 PM
    Last Post: Han
      Input syntax on the Prime Gilles Carpentier 6 1,370 08-23-2013, 04:31 AM
    Last Post: Gilles Carpentier
      Input CAS var on HP Prime Mic 2 846 08-22-2013, 02:29 PM
    Last Post: Mic
      HP 85 Serial Interface; INPUT Example? inaki 1 772 06-12-2013, 11:09 PM
    Last Post: Paul Berger (Canada)
      HP33E how to input numbers RalfGeiger 6 1,283 05-07-2013, 02:41 PM
    Last Post: Ron Ross
      HP 35s - multiple program input values? Arno 3 1,063 04-29-2013, 11:27 AM
    Last Post: Gerson W. Barbosa

    Forum Jump: