The Museum of HP Calculators

HP Forum Archive 18

[ Return to Index | Top of Index ]

OK RPN Purists: Why NOT a big stack?
Message #1 Posted by Brad Davis on 6 Dec 2007, 10:19 p.m.

I have a question for the traditional RPN users around here. I made the transition from RPL (48G, used for > 10 years) to RPN (35s) 3 months ago and am completely used to my 35s at this point. What I want to know is WHY NOT provide a >4 level stack on modern scientific calculators? What would it hurt? I am completely used to starting from the inside, etc., at this point, so am not crippled by RPN, but I see the 4 level stack limit as being, well, really silly and backward-thinking. Someone please tell me why it's necessary.

I actually have one good example of when RPL kicks the snot outta RPN, for me anyway, and I don't think I'll ever get over this. Say I have a large (even 2-3 lines written) equation with nested radical, whatever nastiness one might have, and want to back-solve for one of the variables in the equation. With RPL, 99.9% of the time, I can back out the variable without re-writing the equation. It's probably been over 10 years since I had to re-write one. This is because I don't have to worry about where the "inside" is with RPL. With RPN, I have no prayer at backing out such a variable because I cannot visualize where the inside *will be* for the re-arranged equation. Not a huge issue, but I find myself writing out an equation every so often that I never would've had to re-write with RPL.

There's also the matter of re-using numerical results. It's extremely common to bring something down from 5-6 levels (or more) up the stack and re-use it in RPL. Of course, unless it's very near the bottom, the number is toast in RPN unless I do the TI-like operation of formally storing it somewhere.

I'd say the limit of 4 registers would seem totally asinine to most folks migrating from other calculators also. Frankly, it *looks* like a glitch or error in 2007. When I first laid hands on a RPN machine last year, I actually thought it was an error until I started doing some research.

So what's the deal? I see no advantage to limiting the stack and can't come up with a scenario for which RPN users would actually be screwed up by the presence of a 5th, etc. stack register.

Some enlightenment would be appreciated.

Edited: 6 Dec 2007, 10:21 p.m.

      
Re: OK RPN Purists: Why NOT a big stack?
Message #2 Posted by Dave Shaffer (Arizona) on 6 Dec 2007, 11:09 p.m.,
in response to message #1 by Brad Davis

Quote:
I see no advantage to limiting the stack and can't come up with a scenario for which RPN users would actually be screwed up by the presence of a 5th, etc. stack register

There is at least one advantage of a relatively small stack that many of us are used to: if you are going to use the same number over and over again for a lot of simple calculations (maybe a conversion factor or additive correction to some data you have), it is convenient to fill the stack with that number (by ENTER ENTER ENTER once you've put it in the first time). Then you enter your first data point, hit x (multiply, if that's your need), note the answer, hit <- (for clear), enter your next value, then x again. Repeat as needed. You don't need to recall the constant - it's there for as many times as you need it because the T register is replicated when the current value in the Y register is used.

This is so useful once you get used to it, that I almost automatically hit ENTER the requisite number of times when I start a calculation and think that I just >MIGHT< need my first value again.

            
Re: OK RPN Purists: Why NOT a big stack?
Message #3 Posted by Brad Davis on 6 Dec 2007, 11:20 p.m.,
in response to message #2 by Dave Shaffer (Arizona)

Dave, I thought about that as one advantage, and have used it myself.

However, one can always just tap the enter key a bunch of times really quickly to put such a value way up the stack of a RPL calculator. I guess there might be cases for which this wouldn't work--like you used that value all day, say hundreds of times.

I haven't thought this through, but this might be easily built into a RPL stack. What if the top non-zero stack value was simply replicated all the way up the stack? Seems like that would take care of it, but perhaps there's some pitfall I'm missing. I don't know if that would cause a noticeable reduction in speed.

                  
Re: OK RPN Purists: Why NOT a big stack?
Message #4 Posted by reth on 7 Dec 2007, 12:46 a.m.,
in response to message #3 by Brad Davis

I agree RPL stack is a lot better and the *only* feature I've ever missed from the RPN stack is exactly the automatic copying of the T register. I hope the next calculator has HP48 functionality, HP50 speed and I/O and HP35s size and keyboard (without those ugly cursor keys).

Quote:
What if the top non-zero stack value was simply replicated all the way up the stack?

All the way would mean to infinity ;) or to the memory limits in which case the calculator would not be able to do anything at all.
cheers,
Reth

Edited: 7 Dec 2007, 12:52 a.m.

                        
Re: OK RPN Purists: Why NOT a big stack?
Message #5 Posted by Brad Davis on 7 Dec 2007, 10:38 a.m.,
in response to message #4 by reth

Quote:
... All the way would mean to infinity ;) or to the memory limits in which case the calculator would not be able to do anything at all....

Yeah, that's why it was a developing thought, LOL. I was thinking of smarter algorithms that would copy it "far enough" up the stack or whatever.

      
Re: OK RPN Purists: Why NOT a big stack?
Message #6 Posted by Karl Schneider on 7 Dec 2007, 1:58 a.m.,
in response to message #1 by Brad Davis

Quote:
What I want to know is WHY NOT provide a >4 level stack on modern scientific calculators?

The four levels in the RPN fixed stack of the original HP-35 was most likely considered the "ideal compromise" that was carried forward for all subsequent models. RAM was quite limited in the early days, so a fixed stack was essential. Three elements was and is too constraining (although some National Semiconductor RPN models offered only that), but most users can't juggle five or more elements very well, particularly with only one element visible. Four elements is still enough to solve most problems.

Stack operations are quite a bit simpler with a fixed stack. Exchange and roll down will allow any arrangement of elements; roll up is a convenience. Compare that with RPL's "pick", "roll", "swap", "dup", "over", and whatever else, along with the time-consuming "garbage collection" that is unnecessary in RPN as detritus is simply pushed off the top.

If I were to design a new RPN calc, I'd probably include a fixed stack of user-settable depth, maximum 9-19 elements. Four elements would be the default and minimum stack depth.

-- KS

Edited: 8 Dec 2007, 1:33 p.m. after one or more responses were posted

            
Re: OK RPN Purists: Why NOT a big stack?
Message #7 Posted by reth on 7 Dec 2007, 2:59 a.m.,
in response to message #6 by Karl Schneider

Sys RPL has direct stack operations up to 8 levels IIRC; I guess that is quite a good restriction established by the gurus.

            
Re: OK RPN Purists: Why NOT a big stack?
Message #8 Posted by Brad Davis on 7 Dec 2007, 10:34 a.m.,
in response to message #6 by Karl Schneider

Quote:
... Stack operations are quite a bit simpler with a fixed stack. Exchange and roll down will allow any arrangement of elements; roll up is a convenience. Compare that with RPL's "pick", "roll", "swap", "dup", "over", and whatever else, along with the time-consuming "garbage collection" that is unnecessary in RPN as detrius is simply pushed off the top.

Perhaps an individual preference, but I found roll, swap, etc. to be very easy from day 1.

Quote:
If I were to design a new RPN calc, I'd probably include a fixed stack of user-settable depth, maximum 9-19 elements. Four elements would be the default and minimum stack depth...

Now there I think is a winner of an idea! Make everybody happy--what a concept.

If I had such a calculator, I'd probably set it at 19, but I'd be happy with anywhere from 9 to 19. With RPL, I rarely, if ever, used elements beyond the 6th or 8th one. For one thing, I couldn't see them (48G).

            
Re: OK RPN Purists: Why NOT a big stack?
Message #9 Posted by James M. Prange (Michigan) on 7 Dec 2007, 4:19 p.m.,
in response to message #6 by Karl Schneider

Quote:
Compare that with RPL's "pick", "roll", "swap", "dup", "over", and whatever else,
Although RPL does have many more stack commands available, you could get along with just DEPTH, PICK, ROLL (or ROLLD), and DROPN if you really wanted to. For example, you could use 2 ROLL (or 2 ROLLD) in place of SWAP, 1 PICK in place of DUP, 2 PICK in place of OVER, and so on. See my article "UserRPL stack commands" for more information.

Quote:
along with the time-consuming "garbage collection" that is unnecessary in RPN as detrius is simply pushed off the top.
True, RPL's "garbage collection" (actually, "packing" all still "referenced" objects in temporary memory) does take some time, but in most cases, I find the advantages of a variable stack to more than compensate for the extra time.

One way to speed up each garbage collection is to fill up most of memory with a large "dummy object", but of course the trade-off is that garbage collections will be needed more frequently.

What can drastically slow down the garbage collection is having a large number of stack pointers to elements of composite objects (lists, programs, algebraic objects, unit objects, and, in the 49 series, symbolic matrices), or composite objects themselves, that are in temporary memory. The reason is that if a pointer to an element is on the stack, then the entire composite is kept in memory and referenced for the sake of that pointer, and finding the length of a composite is relatively slow, involving skipping over every object (any of which may itself be composite) in the composite until the tail delimiter object SEMI for the composite if found. For example, if I generate a large list of numbers on the stack, and do a LIST\-> (or OBJ\->), then each of these numbers on the stack (except -9 through 9, which use pointers to ROM objects) is really a pointer into the original list, and garbage collection checks through the entire list for every pointer into it. This slow garbage collection can be avoided by storing the composite object to a global variable and recalling it to the stack, so the pointers are to an object in "user memory" instead of to an object in temporary memory.

Quote:
If I were to design a new RPN calc, I'd probably include a fixed stack of user-settable depth, maximum 9-19 elements. Four elements would be the default and minimum stack depth.
Which stack operations would you want for managing a stack with a user-settable depth?

Regards,
James

                  
Re: OK RPN Purists: Why NOT a big stack?
Message #10 Posted by Karl Schneider on 8 Dec 2007, 2:49 p.m.,
in response to message #9 by James M. Prange (Michigan)

Hi, James --

It's always interesting to read your exacting and informative RPL-specific posts. Excellent article, too.

Of course, these "RPL dynamic stack versus RPN fixed stack" debates have been conducted many times, but we'll hit a few main points for the benefit of those who might not be familiar...

Quote:
Although RPL does have many more stack commands available, you could get along with just DEPTH, PICK, ROLL (or ROLLD), and DROPN really wanted to. For example, you could use 2 ROLL (or 2 ROLLD) in place of SWAP, 1 PICK in place of DUP, 2 PICK in place of OVER, and so on.

Sure, but that's still at least four operations versus two (and an optional third) for RPN. Some of those RPL stack-manipulation commands also require input arguments, which is a bit cumbersome.

Note also that the more-advanced RPN models (e.g., HP-41 and HP-42S) also offer direct STO/RCL access to stack elements.

Quote:
What can drastically slow down the garbage collection is having a large number of stack pointers to elements of composite objects (lists, programs, algebraic objects, unit objects, and, in the 49 series, symbolic matrices), or composite objects themselves, that are in temporary memory. ... This slow garbage collection can be avoided by storing the composite object to a global variable and recalling it to the stack, so the pointers are to an object in "user memory" instead of to an object in temporary memory.

This is all much simpler in RPN. The stack contains only data (numbers and short text strings) and one-word descriptors pointing to matrix data in memory. Stored programs are run using XEQ/GSB and edited in PRGM mode. Another separate mode is provided for editing and running equations.

Quote:
Which stack operations would you want for managing (an RPN) stack with a user-settable (fixed) depth?

Why, the very same ones: x< >y, R_down, R_up, along with CLx for replacement/removal. VIEW, "x < > ST", and "STO/RCL ST" would supplement the four stack-manipulation commands.

Nine stack elements would certainly be enough for any reasonable problem. Even when four elements is not enough, it's easy to access a numbered storage register in RPN with only two or three keystrokes, and not worry about stack overflow.

As all experienced RPN users know, necessary stack depth for computation can be minimized using some foresight. For example, let's say that a car's fuel tank was filled to its 14.7-gallon capacity, and the car's trip computer shows that 323 miles have been traveled since the fill-up at an average efficiency of 25.8 miles per gallon. How much fuel is left in the tank?

The calculation, of course, is

14.7 - (323/25.8) ~= 2.2 gallons

which can be computed as follows:

3 stack levels    2 stack levels

14.7 323 ENTER ENTER 323 25.8 ENTER / 25.8 14.7 / x<>y - -

-- KS

Edited: 18 Dec 2007, 2:29 a.m. after one or more responses were posted

                        
Re: OK RPN Purists: Why NOT a big stack?
Message #11 Posted by Walter B on 9 Dec 2007, 12:52 a.m.,
in response to message #10 by Karl Schneider

Hi Karl,

thanks for your explanation of the RPN world to those who grew up with RPL. Since I was 18 when the 35 appeared, please let me add my 20 Milli-Euros (though the following points may be no news for you):

Quote:
As all experienced RPN users know, necessary stack depth for computation can be minimized using some foresight.
Correct as always. But, the number of such users will continue to decrease significantly if we don't gain enough "newbies" to replace the many old ones passing away. We shall do whatever possible to make their entry into the realm of RPN the easiest. One point is to feature an extra ALG mode to catch them. The next is to let the calc be part of the solution instead of the problem. So, if a bigger stack will ease the path of people becoming "experienced RPN users" then let them have it.

Remember when the 35 appeared, it was a revolution and a revelation and everybody was most willing to take some effort to get rid of function tables. And, since the competing pocket calcs had serious limitations, RPN was THE way to get rid of them, though it required some new thinking.

Nowadays, the world is full of calcs featuring "natural write" or "textbook entry" and the like. So, if you tell a potential new user: "Well, of course you'll have to rearrange your problem a bit, before ..." (s)he will leave before you can finish your sentence advocating the "superiority of RPN". By simply expanding the RPN stack to 8 levels you can completely avoid this discussion at neglegible cost, lowering the entry level. BTW, in parallel you may ease the life of some of the experienced users, though we would never admit ;)

Best regards, Walter

                              
Re: OK RPN Purists: Why NOT a big stack?
Message #12 Posted by Brad Davis on 9 Dec 2007, 11:22 a.m.,
in response to message #11 by Walter B

Quote:
...Nowadays, the world is full of calcs featuring "natural write" or "textbook entry" and the like. So, if you tell a potential new user: "Well, of course you'll have to rearrange your problem a bit, before ..." (s)he will leave before you can finish your sentence advocating the "superiority of RPN". By simply expanding the RPN stack to 8 levels you can completely avoid this discussion at neglegible cost, lowering the entry level. BTW, in parallel you may ease the life of some of the experienced users, though we would never admit...

I couldn't agree more.

I actually tried selling RPN to a younger engineer a couple of weeks ago and he looked at me like I had two heads when I told him that he had to make sure he didn't use more than 4 registers or his answer would be wrong.

One thing I find so objectionable is that it won't give zero, but *some* number, which could even look right, but be totally wrong, due to T-register replication. One man's feature is another man's bug.

I'm sorry guys, but 4 levels might've made sense in 1973 or 1979, but it is practically an "error" or "bug" nowadays.

                              
RPN: larger or variable stack
Message #13 Posted by Karl Schneider on 9 Dec 2007, 5:45 p.m.,
in response to message #11 by Walter B

Hi, Walter --

Your reply was good and thoughtful. I do have one comment to make:

Quote:
By simply expanding the RPN stack to 8 levels you can completely avoid this discussion at negligible cost,

There would be some non-trivial cost in micro-coding and documentation to make the RPN stack larger. I'm not sure how, for example, "roll down" is implemented -- whether it involves copying of data between absolute-reference stack registers or simply changing the values of pointer(s) to one or more stack registers -- but some work would be involved. Documentation would need to be modified, as identifiers for the extra stack levels would be chosen and incorporated into the examples.

Again, I would favor a stack depth user-settable from 4 to 9 instead of a larger fixed depth of 8 or so. A programmable command "STKD" under the MODE menu would fit the bill.

-- KS

Edited: 9 Dec 2007, 10:07 p.m. after one or more responses were posted

                                    
Re: RPN: larger or variable stack
Message #14 Posted by Walter B on 9 Dec 2007, 6:50 p.m.,
in response to message #13 by Karl Schneider

Quote:
I would favor a stack depth user-settable from 4 to 9 instead of a larger fixed depth of 8 or so.
So do I -- please see my contribution to HHC2007 and also my post at 1:04 a.m. today. A maximum of 8 levels will do.
Quote:
A programmable command "STKD" under the MODE menu would fit the bill.
I called it STSIZE and put it into MODES some 2 years ago :)
                        
Re: OK RPN Purists: Why NOT a big stack?
Message #15 Posted by James M. Prange (Michigan) on 9 Dec 2007, 10:51 p.m.,
in response to message #10 by Karl Schneider

Hi Karl,

I really don't expect to convince you that RPL is easier to use than Classic RPN, but indeed some others may benefit from reading of some advantages and disadvantages of each.

Quote:
Sure, but that's still at least four operations versus two (and an optional third) for RPN. Some of those RPL stack-manipulation commands also require input arguments, which is a bit cumbersome.
True, but these four operations (and any required arguments) should be easy enough to remember. Actually, if you remember how many stack levels there are, you could get along without DEPTH.
Quote:
This is all much simpler in RPN.
Simpler for the designer, or simpler for the user?
Quote:
The stack contains only data (numbers and short text strings) and one-word descriptors pointing to matrix data in memory.
Well, strictly speaking, the RPL user stack contains only 5-nibble pointers to objects elsewhere in memory. How's that for simple?

I do think that the garbage collection routine could stand some improvement. Even if an object in temporary memory happens to be referenced by more than one pointer, should it really be necessary to find its end more than once? And could the length of composite objects be stored before the composite objects themselves in temporary memory, making it much easier to find their ends? It seems to me that JYA had a scheme something like that for speeding up garbage collection with referenced composites, but ACO was closed down before it was implemented.

Garbage collection is usually no more than a very minor annoyance, but RPL users should be aware of situations that can make it a major problem, and how to work around these.

Quote:
Stored programs are run using XEQ/GSB and edited in PRGM mode. Another separate mode is provided for editing and running equations.
Separate modes for programs is simple? Not having separate program modes was, for me, one of the benefits of switching to the 28S way back then.
Quote:
Why, the very same ones: x< >y, R_down, R_up, along with CLx for replacement/removal. VIEW and "STO/RCL ST" would supplement the four stack-manipulation commands.
Okay, so you'd sometimes be pressing R_down or R_up repeatedly? It seems to me that, depending on your chosen stack depth, that might get a bit tedious. Some might find it convenient to have a few more stack manipulation commands available, even though not actually required.
Quote:
Nine stack elements would certainly be enough for any reasonable problem. Even when four elements is not enough, it's easy to access a numbered storage register in RPN with only two or three keystrokes, and not worry about stack overflow.
And in RPL, it's easy enough to access a named variable, and there's never any need to worry about "stack overflow", as it just can't happen.
Quote:
As all experienced RPN users know, necessary stack depth for computation can be minimized using some foresight. For example, let's say that a car's fuel tank was filled to its 14.7-gallon capacity, and the car's trip computer shows that 323 miles have been traveled since the fill-up at an average efficiency of 25.8 miles per gallon. How much fuel is left in the tank?

The calculation, of course, is

14.7 - (323/25.8) ~= 2.2 gallons

which can be computed as follows:

3 stack levels    2 stack levels

14.7 323 ENTER ENTER 323 25.8 ENTER / 25.8 14.7 / x<>y - -


Sure, and in RPL, available memory permitting, there's no need to minimize the number of stack levels used. You can simply put the arguments (however many) on the stack and leave them there until they're needed for an operation. For your example, I could simply key in:
14.7 323 25.8 / -
and get the answer. Even if I happen to have dozens of arguments on the stack at any given time, I don't have to concern myself with the possibility of anything being pushed off of the top of the stack into the "bit bucket"; at worst, I'd get into an insufficient memory condition. Nor do I have to worry that an object is actually a replicated T level instead of what would have been in that level if the stack were deeper.

Or I could use an algebraic object, and key in: '14.7-323/25.8', or use the equation writer to key in the expression, and then press EVAL. When I happen to actually have the expression correctly written out in front of me, using an algebraic object is often easier.

Regards,
James

                        
Re: OK RPN Purists: Why NOT a big stack?
Message #16 Posted by Walter B on 19 Dec 2007, 2:26 p.m.,
in response to message #10 by Karl Schneider

Karl, when you edit after 10 days, would you please indicate what you have changed?

                              
Re: OK RPN Purists: Why NOT a big stack?
Message #17 Posted by Karl Schneider on 19 Dec 2007, 11:35 p.m.,
in response to message #16 by Walter B

Quote:
Karl, when you edit after 10 days, would you please indicate what you have changed?

Hi, Walter --

Very little was changed; I simply added a reference to the useful "exchange with stack element" feature on the HP-41/42 that I'd forgotten about, as I indicated in my reply to Antoine. I'm certainly not trying to "put one over" on anyone, but I wanted to get it complete and correct for the Archives.

Quote:
VIEW, "x < > ST", and "STO/RCL ST" would supplement the four stack-manipulation commands.

Regards,

-- KS

Edited: 19 Dec 2007, 11:36 p.m.

                                    
Re: OK RPN Purists: Why NOT a big stack?
Message #18 Posted by Walter B on 20 Dec 2007, 2:09 a.m.,
in response to message #17 by Karl Schneider

Thank you!

            
Re: OK RPN Purists: Why NOT a big stack?
Message #19 Posted by John Keith on 9 Dec 2007, 1:23 p.m.,
in response to message #6 by Karl Schneider

Actually, HP's first calculator, the 9801A, had a 3-level stack and several RPN quirks- e.g. the results of calculations went into the Y register, not the X. A complete description can be seen in the Sept. 1968 issue of the HP Journal, available on the Museum DVDs and at

http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1968-09.pdf

John

            
Re: OK RPN Purists: Why NOT a big stack?
Message #20 Posted by Stefan Vorkoetter on 10 Dec 2007, 9:33 a.m.,
in response to message #6 by Karl Schneider

For anyone that has a PDA, I'd suggesting trying out MathU pro, a very HP-like programmable calculator app for the Palm and Windows Mobile PDAs. I've had this program for years, and it's great.

http://www.creativecreek.com

What's relevant to this thread is that it has a user settable stack size of either 4 or 16 elements. Originally, it only had a 16 element stack, but I suggested they have a setting to allow a 4 element stack in order to ease porting of HP programs, and the author acted on my suggestion.

Note that this program doesn't emulate any particular HP calc. It is its own calculator, very strongly based on HP RPN operating principles. The programming is slightly more sophisticated than the HP RPN calcs, adding such things as input dialogs, and structured if and loop statements.

By the way, the latest version adds a "Red LED" skin.

Stefan

(no connection to Creative Creek, other than as a satisfied customer and idea contributor)

                  
Re: OK RPN Purists: Why NOT a big stack?
Message #21 Posted by Walter B on 10 Dec 2007, 11:41 a.m.,
in response to message #20 by Stefan Vorkoetter

I second this. To add one point: MathU Pro allows you to fully customize your virtual keyboard. AFAIK the only constraints are:

  • 31 keys
  • 2 shift keys
  • max. 3 functions per key for 23 keys, max. 2 functions per key for 6 keys
  • no menues
  • many numbered registers, but named variables only as in 32s, 33s, 35s.
Function set is smaller than the one of 42S. Programming function set is expanded as Stefan mentioned.

HTH, Walter

(also no connection to Creative Creek, other than as another satisfied customer and idea contributor)

      
Pseudo-Extended Stack
Message #22 Posted by Namir on 7 Dec 2007, 8:45 a.m.,
in response to message #1 by Brad Davis

Brad,

The 4-level stack has proven to be quite useful over several decades of HP calculator life. The HP graphing calculators have a flexible stack, which is the other design.

What I suggest, since memory is becoming abundant in calculators, is the following system. Keep a 4-level stack, but add the ability to push and pop the T, Z, and Y registers into the memory. This system allows you to temporarily save these registers in order to do more stack based calculations, and then restore the registers when you are done. In other words, the user can dynamically pseudo-extend the stack.

I have also thought about multi-stack systems, but the above suggestion can replace the multi-stack system, and is simpler.

Namir

Edited: 7 Dec 2007, 8:46 a.m.

            
Re: Pseudo-Extended Stack
Message #23 Posted by Brad Davis on 7 Dec 2007, 10:43 a.m.,
in response to message #22 by Namir

Quote:
...The 4-level stack has proven to be quite useful over several decades of HP calculator life.

Sure, but I had no trouble finding disadvantages of it (inability to back out a variable in a complicated equation, retrieving a value to be used again without storing it, etc.). Nobody's really come up with compelling advantages so far, IMO.

Quote:
...What I suggest, since memory is becoming abundant in calculators, is the following system. Keep a 4-level stack, but add the ability to push and pop the T, Z, and Y registers into the memory. This system allows you to temporarily save these registers in order to do more stack based calculations, and then restore the registers when you are done. In other words, the user can dynamically pseudo-extend the stack. ...

Strikes me as being fairly counter-intuitive.

I like the user-defined stack size a lot better. It's really beyond me why that hasn't been done already. Really seems pretty basic.

Or...make the stack 10 deep. I'd be perfectly happy with that. Would that really make it harder to use for any of you fellows? ;) If someone wanted to copy the value up to the T register so that it would be replicated indefinitely, pressing Enter 9-10 times probably takes about 2 sec., if that.

                  
Re: Pseudo-Extended Stack
Message #24 Posted by Maximilian Hohmann on 7 Dec 2007, 11:03 a.m.,
in response to message #23 by Brad Davis

Hello!

Quote:
inability to back out a variable in a complicated equation, retrieving a value to be used again without storing it, etc.

I don't really see the difference between storing a value in memory or storing it somewhere down the stack. And if the stack is really large, then retrieving a value becomes painful bacause I have to browse through the whole stack for my value (remembering stack positions is useless, because they change all the time).

But this is probably all a matter of habit anyway, so a user-configuarable stack size is best!

Greetings, Max

                  
Re: Pseudo-Extended Stack
Message #25 Posted by bill platt on 7 Dec 2007, 11:06 a.m.,
in response to message #23 by Brad Davis

The only good reason for the 4 level stack is backwards compatibility. That's the only good reason.

I'm a 20+ year veteran of RPN and it is great, but RPL is so much better overall. But I do use the constant effect of RPN quite often.

Really, RPN to me is totally outmoded and of historical importance only, with respect to programming and large tasks. RPL is exasperatingly large learning time, but even at the rudimentary level is far better for bigger stuff than RPN. It has real I/O for instance.

Past a certain size of task, neither are worth using and that's the practical reality.

But for afficianados such as me, using a 15c for sonething useful for which it is still as good as any new machine, that is the fun of calculator collecting!

      
Re: OK RPN Purists: Why NOT a big stack?
Message #26 Posted by Antonio Maschio (Italy) on 7 Dec 2007, 11:38 a.m.,
in response to message #1 by Brad Davis

For me there's only one thing to say:

A 4-level stack is sufficient for all calculations, and using the roll-down, roll-up, ENTER, x<>y and Clx keys lets the user control the whole stack in few steps.

That's why it has survived quite unchanged for 35 years.
(Of course this is meaningful only to RPN users.)

-- Antonio

            
Re: OK RPN Purists: Why NOT a big stack?
Message #27 Posted by Brad Davis on 7 Dec 2007, 1:19 p.m.,
in response to message #26 by Antonio Maschio (Italy)

Quote:
For me there's only one thing to say:

A 4-level stack is sufficient for all calculations...


Not to be argumentative, but I refuted that in the first post: the inability to know where the "inside" is after an equation is turned all different ways to back-out a variable.

I'll re-state it. Say I have a 3-line equation written out and it has lots of nastiness such as nested radicals, etc. It's been years since I ran across an equation that I couldn't back out any variable at any location in such an equation using RPL. I'm sure others can do this also. Of course, this is limited to closed-form equations. If I have "x" in the exponent in one term and inside a cosine in another, I can't just back that out. To be completely precise, I should've typed that I "can back out variables MUCH MORE OFTEN with RPL than RPN" because there are obviously equations out there for which I couldn't do it with either--just very rare with RPL.

This only works because I don't have to give a rip about running out of stack. I don't have to try and figure out where the inside will be and plan my way from inside to outside.

I've tried a few times with RPN and just can't accurately enough go from inside to outside without re-writing it so that I can see it.

If you would've typed "99% of calculations" then I would totally agree.

Keeping to 4 levels seems bull-headed to me and without real usefulness.

Edited: 7 Dec 2007, 1:31 p.m.

      
Re: Stack depths -- each has its application.
Message #28 Posted by Paul Brogger on 7 Dec 2007, 12:20 p.m.,
in response to message #1 by Brad Davis

I'd say the two extremes (4-level RPN or "infinite"-level RPL) address two different situations. 4-level is great for keyboard-entry (that is, non-programmed) use, as it's relatively easy for the user to keep track of what's where. It can be something of a limitation when programming -- a limitation that is overcome by addressing storage registers.

The RPL stack is best suited for programming, where one may carefully craft and debug applications that keep track of stacks of greater depth. It also generalizes subprogram calls, allowing consistent use more than four parameters. It's somewhat more cumbersome when used from the keyboard -- to which the necessarily more complex stack-related instruction set clearly attests.

But (and here we'll no doubt get controversial) I've long bought into the assessment that stack-based programming languages, despite the beguiling elegance of the LIFO motif (if that's the right word), basically suck from a program clarity and proof-of-correctness standpoint. In general, at any arbitrary point in the code, one simply can't guarantee what has been left in the next several stack entries upon which your code will depend. The possibilities for problems abound. This vulnerability can be overcome by the careful coding and testing of an alert devotee, but for the rest of us, a stack-based programming language is a thousand accidents waiting to happen.

(And yes, most any compiler or interpreter is going to utilize stacks in the background, but that alone doesn't constitute a "stack-based programming language", in the sense of the user manipulating storage primarily and directly, via a stack.)

My few $0.01 worth -- ever declining in value with advancing age and the falling dollar.

Edited: 7 Dec 2007, 12:29 p.m.

            
Re: Stack depths -- each has its application.
Message #29 Posted by Brad Davis on 7 Dec 2007, 1:24 p.m.,
in response to message #28 by Paul Brogger

Quote:
I'd say the two extremes (4-level RPN or "infinite"-level RPL) address two different situations. 4-level is great for keyboard-entry (that is, non-programmed) use, as it's relatively easy for the user to keep track of what's where. ...

Interesting. I see it as the exact opposite, undoubtedly because I used RPL from age 18 to 36. For me the 4-level causes me to have to think more because I have to keep track of what's NOT where because it got pushed off the top of the stack.

I really hope HP develops a calculator that's as elegant as the 35s and includes user-defined stack size. That's the best of both worlds and a no-brainer IMO after reading this thread so far.

As for calculator programming, I have no personal application for that. I have Excel, Mathcad, Matlab, and C++ (in order, depending on the level of the problem) for that. I've always found RPL programming to be heinously difficult and frustrating. I know others have uses for this, but I never have.

Edited: 7 Dec 2007, 2:14 p.m.

                  
Re: Stack depths -- each has its application.
Message #30 Posted by Paul Brogger on 7 Dec 2007, 2:16 p.m.,
in response to message #29 by Brad Davis

Quote:
I really hope HP develops a calculator that ... includes user-defined stack size ...

If done well, that could answer the RPL/N folks' varying wants. With regard to RPN's auto-replication of the T entry -- a "FILL" command that would replicate X throughout a finite stack (however deep it is defined to be), and auto-replication of the top (wherever located) might satisfy that desire for all.

However, making the stack more flexible will necessarily increase the size and complexity of the stack-related command set, and presenting the RPN keyboard options (Enter, X<>Y, Roll, Drop) simply as such may be precluded.

                        
Re: Stack depths -- each has its application.
Message #31 Posted by James M. Prange (Michigan) on 7 Dec 2007, 5:28 p.m.,
in response to message #30 by Paul Brogger

The only advantage that I see to a fixed-depth stack is the auto-replication of the T register (or pointer, in an RPL-like implementation). To be sure, there are work-arounds, such as pushing a number of copies to the stack, or using a DEPTH PICK sequence to copy the top-most level to level one and then n ROLLD to move it to wherever it's needed, or simply storing it to a variable and recalling it as needed, but they're not the same, and I really don't see a way to implement it with a variable-depth stack.

Quote:
If done well, that could answer the RPL/N folks' varying wants. With regard to RPN's auto-replication of the T entry -- a "FILL" command that would replicate X throughout a finite stack (however deep it is defined to be), and auto-replication of the top (wherever located) might satisfy that desire for all.
Yes, I expect that either of these would be easy enough to implement with any fixed-depth (including user-definable depth) stack.

I can imagine being able to define a stack depth to any number (memory permitting) that the user chooses, or to "variable". Perhaps setting the depth to "0" could be treated as choosing the variable-depth stack? Operations that required a fixed-depth stack could simply error out when the variable-depth stack was active.

Quote:
However, making the stack more flexible will necessarily increase the size and complexity of the stack-related command set, and presenting the RPN keyboard options (Enter, X<>Y, Roll, Drop) simply as such may be precluded.
Not necessarily any larger or much more complex (see my earlier post), but certainly having a larger and more flexible stack-related command set for dealing with a more flexible stack does seem very desirable.

Regards,
James

                  
Re: Stack depths -- each has its application.
Message #32 Posted by Martin Pinckney on 7 Dec 2007, 3:13 p.m.,
in response to message #29 by Brad Davis

Quote:
I really hope HP develops a calculator that's as elegant as the 35s and includes user-defined stack size. That's the best of both worlds and a no-brainer IMO after reading this thread so far.

Hoping won't go too far :-). Or dreaming, as is frequently done on this forum.

email HP with your desires for a new scientific calculator model. I have; the first two times I got a auto-generated reply, after the 3rd I got a real reply from a real person. He said he had been passing my ideas along to the "future products marketing manager". BTW, he also said "we do have a couple people in our group who do read through the MoHPC occasionally mostly looking for problems with our new products." So maybe the bugs in the 35s will be fixed someday?

            
Re: Stack depths -- each has its application.
Message #33 Posted by bill platt on 7 Dec 2007, 3:26 p.m.,
in response to message #28 by Paul Brogger

But the great thing about RPL machines is that you have a structured programming language available--you don't have to do stack games if you don't want to.

I actually like the stack aspect for manual calcs. The power of RPL for big stuff is the seamless use of algebraic expressions, solver, integrator and RPN commands--it makes for a very powerful and flexible tool.

                  
Re: Stack depths -- each has its application.
Message #34 Posted by Gerry Schultz on 7 Dec 2007, 7:29 p.m.,
in response to message #33 by bill platt

Here's my 2 cents on the subject. I've been reading William C. Wickes excellent "HP41/HP48 Transitions" book as I come from the HP-55 and HP-41 world starting back in the mid-70s, so this book is written from my perspective. In this book, Bill brings out the point that all 48 commands get their input from the stack and output back to the stack. If the stack was limited to 4 levels, executing commands could destroy any prior user data that was on the stack.

Also, Bill talks about there no longer being a need for indirect addressing as used in the 41 because of the unified memory structure in the 48 and that all commands are truely postfix, as opposed to some 41 commands. Finally, he also stresses that with the larger memory in a 48, structured programming is easier to implement than on a 41 so there is no GTO in the 48.

As noted by Karl Schneider and Paul Brogger, I think RPN is great for those calculators that had limited, expensive memory and the 4-level stack depth is a good compromise. With greater amounts of cheaper memory available, the shift to RPL was the only way to go and with its greater flexibility, comes greater complexity and programming becomes more structured. So the stack depth had to be increased to accommodate the more complex 48 commands.

In the end, for me, I prefer the RPN style of stack simply because I'm use to it. The RPL style is great but I don't naturally think that way when I'm using the 48. Now that I am trying to write a program for the 48 (which is why I'm re-reading the Transitions book), I will have to completely re-think the logic of my original 97, now 41 program so it will run on a 48.

I have struggled for years (I now have a 48GX, 49G, 49g+ and a 50g) to understand RPL and now I am taking the time (my wife thinks I'm totally nuts!) to figure it out, it's become more of a challange and less of a pain in the tukas.

I don't have a 35s (I knew I should have gone to the San Diego conference) and am surprised that its stack depth is limited to four. For HP, I think that is a mistake. As I understand it, the 35s processor is the same as the 33s and HP had to fit more functionality in it, so they dropped some 33s functions and shoehorned in the new 35s functions. I hope that when HP releases the successor to the 35s, that it adds a user-selectable stack depth so whether you come from the RPN or RPL world, the calculator will be more familiar.

For what it's worth,

Gerry

                        
Re: Stack depths -- each has its application.
Message #35 Posted by Walter B on 9 Dec 2007, 1:04 a.m.,
in response to message #34 by Gerry Schultz

Hi Gerry,

fully agree with your post. I'd advocate a settable stack depth of up to 8 levels for RPN.

FWIW

      
Re: OK RPN Purists: Why NOT a big stack?
Message #36 Posted by Nick on 9 Dec 2007, 9:07 p.m.,
in response to message #1 by Brad Davis

Well Brad, perhaps because we have to do with grandfathers and their nostalgia? Because we grandpappies think that all past was better? Maybe that's all?

Maybe all arguments for a limited stack size, for only numbers/data on stack, for dedicated buttons, for.. whatever can name it... maybe it's only the wish to catch again that great dreaming enthousiasm of our younger years, when we made the impossible possible just for the joy? Could that state be ever tangible again using such things like limited stack sizes? Or we perhaps still think that *our own* golden age just has to be *the* golden age of all ages? ;-)

But we are in 2007, if I remember well, and nostalgia *will* die along with us. The future might be not what we like it to be, but the future never really cared about what "we" like, just as it never cared about the fact that the grandpappies of 1970 told us about such things like "ease of use" and "foolproof work" of their slide rules, when *we* were the next steps?

So you can see that it's all not really an argument but just simple plain getting used to. Of course I like the limitations of the oldies, for whatever reasons, but is this liking really such a big argument against the concentrated power of the future?

Let's think of it a bit more objectively, and also a bit more open for new things to come, which includes much more than the limited picture of the world than some old fashioned engineer might have. Oh, and not to forget, there are are also *scientists* working out there! ;-)

We, grandpappies, should also wonder why we still swear to Jimmy Hendrix while he is only a dwarf againt Edward Lodewijk, you know, they flying Dutchman. ;-)

For a more serious approach, there is an infinite number of problems that is never going to be solved using just a tiny, crippled, devastating limited stack in size and in sence of data. In other words, there are much more important problems to be solved than the construction of, say, a bridge, by just using a handheld device. If we can't imagine that, then we are already dead. ;-)

The next step will definitely not de just some laughable limited calculating unit, but rather some device of supreme *mathematical* power, and as I can only hope, either we get used to that too, or we go rusty. So, forget about the past, here is today!

My next scotch to us all, grandpappies of X-Y-Z-T ages. What a waste we can be! >:-D

Nick

            
Re: OK RPN Purists: Why NOT a big stack?
Message #37 Posted by Walter B on 10 Dec 2007, 1:26 a.m.,
in response to message #36 by Nick

:-D

Hi Nick, well analyzed for sure :-)

Nevertheless, one comment: Looking to the market of "scientific" calcs, it seems the big share is not taken by "some device of supreme *mathematical* power" but by a lot of bread and butter calcs, just featuring a more or less complete set of "scientific" operations on top of SQRT. So for most tasks in the real world, "some device of supreme *mathematical* power" seems to be overkill. AFAIK the other grandpappies, we simply wish to show up in the real world with a small and decent (understatement!) updated 42S instead of a big fancy student calc loaded with bells and whistles we'll never blow (again ;-))

IMHO if the 42S would be reissued with an LCD of nowadays resolution, allowing to show some more lines, and supporting some I/O, this will catch 80% of our wishes. Add beveled keys, a (settable) larger stack size, and an extended allowance for CUSTOM or USER functions, and you'll see the forum dance. Hoping to experience this once before I die,

best regards,

Walter

Addendum: Shouldn't we rather strive for "supreme *mathematical* power" in our brains than in a tool?

Edited: 12 Dec 2007, 5:42 p.m.

      
Why not a 6 level Stack ? Re: OK RPN Purists: Why NOT a big stack?
Message #38 Posted by Antoine M. CouŽtte on 17 Dec 2007, 7:48 a.m.,
in response to message #1 by Brad Davis

Dec 17, 2007

Brad,

Sorry to show up so late, but I wanted to reply to your query about stack lenght.

As I explained earlier, and after a few thousands hours spent on programming, refining and debugging programs on the HP41, maybe the best welcome addition to the HP41 Stack would be a 6 level stack ( + Last X of course ) with X, Y, Z, T + A & B for example - with B register automatic replicating of course when the stack goes down - altogether with a complete set of one byte instructions to swap its registers ( Z<>A , T<>X ... ).

You can still keep track of a 6 level stack in your mind and the programming versatility and flexibility would be greatly enhanced.

In ASTRONAV Programming, I have encountered a number of situations where a 6 level or even a 5 level stack would have kept all calculations within the stack ( solving Keplerís equation being one such example ).

Best Regards from

Antoine M. CouŽtte

            
Re: Why not a 6 level Stack ? Re: OK RPN Purists: Why NOT a big stack?
Message #39 Posted by Raymond Del Tondo on 17 Dec 2007, 10:15 a.m.,
in response to message #38 by Antoine M. CouŽtte

Slightly OT,

but my SpeedUI for the HP-48G Series calcs actually shows a 6-level stack,
or more exactly the first six stack levels (SCNR;-)

Regards

Raymond

            
Why not a stack settable to 8 levels max.? (Re: Why not a 6 level Stack ?)
Message #40 Posted by Walter B on 17 Dec 2007, 12:21 p.m.,
in response to message #38 by Antoine M. CouŽtte

Bonjour (bonsoir?) Antoine,

if somebody with your experience requests 6 stack levels, this has to be taken seriously. Please allow me to add 3 proposals:

  1. let the (repeating) top stack level keep its name "T" (so we'd have e.g. X, Y, Z, 4, 5, T);
  2. add 2 more stack levels optionally for reasons mentioned above;
  3. allow the user to set the stack size to any value from 4 to 8 (4 for backward compatibility, bigger sizes according to individual needs).

Salutations,

Walter

Edited: 17 Dec 2007, 12:35 p.m.

                  
Re: Why not a stack settable to 8 levels max.? (Re: Why not a 6 level Stack ?)
Message #41 Posted by Antoine M. CouŽtte on 17 Dec 2007, 4:32 p.m.,
in response to message #40 by Walter B

Hello Walter,

Thank you for your ideas here.

8 levels ? Why not ?

1 - I buy most of your point # 1, i.e. labelling the upper level as "T". As always, we NEED T replication when the stack drops. Still I would be maybe a bit more reluctant to use numbers - i.e. "4" & "5" - even to label levels 4 & 5. I had earlier suggested "A" & "B" simply because, to the best of my knowledge, all registers - whether "Classical" or "Synthetic" - are labelled with letters. How about X, Y, Z, A, B, T + L ( Last X ) ?

2 - Why not 8 levels ? I still would buy it, but with 2 caveats. First, it will be almost impossible to mentally keep track of "what is where" in the stack. Second, an 8 level stack can only be operational if you have a minimum set of 1 byte instructions to manage the stack ( A<>T , X<>A ... ). From 4 to 6 levels, the instruction set greatly increases. If you jump from 6 to 8, that is another much more complex story !!!

2/3 - The only and Main Point I would certainly ( and firmly ) question is the " User Defined Size " option. What about the compatibility between programs ? How will you GTO or XEQ programs with different stack lenghts ? Would you have to code it at the onset of each program, including at the beginning of EACH subroutine which might be later called upon? It may be a Reeeal Problem.

Last question : how can software already written for 4 level stacks be made compatible on a 6 or 8 level stack machine ?

Much to think about it ...

Best Regards

Antoine

                        
Re: Why not a stack settable to 8 levels max.? (Re: Why not a 6 level Stack ?)
Message #42 Posted by Walter B on 17 Dec 2007, 6:29 p.m.,
in response to message #41 by Antoine M. CouŽtte

Bonsoir Antoine,

merci pour votre response.

I fully agree with your point #1. Letters denoting all stack levels will be more consistent.

Ref. to your point #2, IMHO x<>y, RUP and RDOWN are still sufficient to "manage the stack" of any RPN calculator. The bigger stack size should just take care of complicated mathematical expressions and/or users calculating straightforward, cutting the necessity to rearrange equations before solving them. I did not intend to permutate each and every stack level, which would indeed require a large number of instructions as you pointed out rightfully.

Also my approach to the "User Defined Size" is simpler: I expect most routines running in "Compatibility Mode", i.e. with stack size 4. If, however, a particular routine needs more levels, you are free to increase the stack size - and shall reset it before returning from this routine. STSIZE n will be a programmable instruction. I did not intend to transfer parameters or the like on the stack - I want a comfortable RPN, not RPL.

These are some aspects which were already thought about. Hope it answers some of your concerns. If there are more, don't hesitate.

Salutations,

Walter

                              
Re: Why not a stack settable to 8 levels max.? (Re: Why not a 6 level Stack ?)
Message #43 Posted by Antoine M. CouŽtte on 17 Dec 2007, 11:10 p.m.,
in response to message #42 by Walter B

Hello Walter,

Quote:

Ref. to your point #2, IMHO x<>y, RUP and RDOWN are still sufficient to "manage the stack" of any RPN calculator.


I really think that " x<>y, RUP and RDOWN ", if absolutely necessary to manage a RPN stack, are definitely NOT sufficient to adequately manage even a 4 level stack. You at least need to exchange X level with any other level. If I remember correctly, 41CX implemented this extended stack operation and this was a definite improvement over plain 41C.

I agree that with a 6 or 8 level stack ( + the LAST X level which sometimes seems to be overlooked ) swapping or copying any register into any other one might be " unecessary overkill " , but a well thought " stack management kit " must necessarily contain definitely much more than the mere " x<>y, RUP and RDOWN " instructions.

Back to the well known " Kepler's Equation " , which is a pretty simple one, and if only with " x<>y, RUP and RDOWN " , I not sure at all - although I have not studied this particular case again - that an extra 2 or even 4 levels will definitely enable you solving this equation within the stack itself, unless you are forced to use a quite extended number of the 3 instructions here-above.

We should not forget that one of the beauties of RPN is its concision in terms of occupied computer space. The drawback is that it is sometimes difficult to decipher programs. With a 8 level or even a 6 level stack, if we are left with only " x<>y, RUP and RDOWN " instructions, stack management will require far too many of these instructions for lack of a more comprehensive tooling package. And with this unavoidable " extra use of space " you will loose one of the main benefits of RPN : its concision in terms of occupied space.

Only additionnal extended testing with a multiple people team - in complement of what has been done so far - can devise an adequate " stack management tooling set " which can address most situations. Again, and to save programming space, I would insist on having only 1 byte instructions available in the " stack management kit " if achievable.

I think that the above covers most of my own reflexion and analysis over this quite interesting topic.

And in conclusion, when I earlier wrote

Quote:

Much to think about it ...


I rather should have written " Much to test about it ".

Best Regards

Antoine

                                    
Re: Why not a stack settable to 8 levels max.? (Re: Why not a 6 level Stack ?)
Message #44 Posted by Karl Schneider on 18 Dec 2007, 2:47 a.m.,
in response to message #43 by Antoine M. CouŽtte

Welcome back, Antoine --

Quote:
You at least need to exchange X level with any other level.

Thank you for reminding me of the ability of the open-ended "x < >" to exchange contents with stack registers as well as storage registers, along with indirection. It's an important feature, and I have modified one of my earlier posts in this thread to include it.

Quote:
If I remember correctly, 41CX implemented this extended stack operation and this was a definite improvement over plain 41C.

Alas, your recollection was imperfect...

;-)

All three versions of the HP-41, as well as the HP-42S, offer the full-featured "x < >". The HP-42S can also exchange contents with a named variable, or (via indirection) the register its contents "point to".

As general information, the functions unique to the HP-41CX (i.e., not available on the 82182A Time Module or the 82180A X-Functions) are listed separately by the "CATALOG 2" command under the respective categories "-CX TIME" and "-CX EXT FCN". This segregation helped the programmer/user to ensure full compatibility of HP-41 programs.

The HP-15C also has an open-ended "x < >" for storage registers, matrix elements, and indirection via the I-register, but stack registers are not available for the command.

Regards,

-- KS

(added some info for completeness)

Edited: 22 Dec 2007, 6:33 p.m.

                                    
Re: Why not a stack settable to 8 levels max.?
Message #45 Posted by Walter B on 18 Dec 2007, 3:26 a.m.,
in response to message #43 by Antoine M. CouŽtte

Bonjour Antoine,

first of all, I must admit I simply forgot x<>. Sorry. But why? Because I use it to swap the contents of x and registers - I never used it to swap stack levels so far (too cumbersome).

My understanding of the stack is very simple: a temporary storage where I push all the intermediate results until I need them, allowing me to forget to take care of closing parentheses, operator precedence and the like. x<>y is the only "stack management instruction" I really need and often use. I appreciate top level repetition, so FILL to fill the entire stack with the contents of x in one step may be a nice (=time saving) additional instruction. But that's it! I want a calculator - like any tool - to ease my tasks.

I hardly make use of the roll commands except in very tricky programs where storage space limitations matter or where I want to impress anybody (including myself) because I am able control such demanding operations (they demand me to take a piece of paper to denote the stack contents, since even 4 are too much for my little brain). Both happens scarcer as time goes by, since storage space becomes abundant and people understanding keystroke programming become less in my environment. And in the time needed to fiddle around swapping or rotating stack levels (imagine this in a meeting: a nightmare!) I can solve the problem on my PC - though far less elegant, but effective.

This is my simple use of RPN. Call it primitive, so what? The "real world" is complex enough, so a calculator featuring an elegant (=powerful and user friendly) OS like RPN is the right answer IMHO. 8 stack levels would relieve even newbies from taking care of stack limits. 8 levels still allow to take care for them manually without FILL. 8 levels may catch some ALG-users (and keep them long enough to convince them by the elegance of RPN) who we need desperately to let this OS survive. So keep it simple and elegant. For the nerds, we still have RPL ;-)

Just my 20 Milli-Euros, of course.

Salutations,

Walter

Edited: 18 Dec 2007, 3:31 a.m.

                                          
Re: Why not a stack settable to 8 levels max.?
Message #46 Posted by Antoine M. CouŽtte on 18 Dec 2007, 7:24 a.m.,
in response to message #45 by Walter B

Thank you again for your reply Walter.

I fully buy your FILL and STSIZE instructions which seem to very nicely respond to my concerns about 4/6/8 level stacks Program Compatibility ( still 1 byte instructions :-)) ? ) .

Quote:

My understanding of the stack is very simple: a temporary storage where I push all the intermediate results until I need them, allowing me to forget to take care of closing parentheses, operator precedence and the like. x<>y is the only "stack management instruction" I really need and often use.


It then looks that - as every single Programmer/User in the vast majority of cases - you do not use the systems possibilities to their full extent in every single direction.

The very same holds true for me : I have almost never used LN , EXP or LOG in my Astronomical or Aircraft Fuel Management Software since I simply do not need these functions for my usual applications. This is certainly not a reason to "dump" such functions which are a must for a number of other Programmers/Users.

By comparison with the above :

FIRST I will certainly not question the way you have used the RPN stack,

SECOND, I would only notice that you look satisfied with a " reduced set " of Stack Management Instructions. Therefore, a more comprehensive " tool set " would be of little interest to you. However, should this be a reason to deprive other Users/Programmers from having a more comprehensive set of Stack Management Functions available at fingertip to manage their 6 or 8 level RPN stack ?

Quote:

For the nerds, we still have RPL ;-)


This is very true, but unfortunately, RPL - if you mean here the HP48GX programming User language - is much less intuitive than RPN. After a few days of hard learning, including Richard Nelson's early HP28/48 courses and after studying Bill Wickes's Book on HP28/48, I realized that just after a few weeks of non-practice, I would forget almost everything.

The RPN concept is so much easier than RPL for me in this respect : just 5 numbers in the stack. Play with them through all familiar " operators " learnt at school ( +, - , x , / , SIN, ASIN, EXP , LN, .... ) and simple Stack Operators. Should you resume working on RPN after months, or more : here again you are immediately "home", even if such "home" does not have - and by far - the latest and most modern commodities.

This is why I stick to RPN on a handheld.

Otherwise, instead of RPL even on a handheld, I would rather go into learning BASIC for a Handheld. It should not be too much difficult since I did practice FORTRAN2 ... many moons ago !!. Why BASIC ? Simply because Valentin Albillo so superbly gives us here demonstrations of the power of this language.

And, by the way there are also superb HP71 Emulators on the Market both for Laptops and for Handhelds.

In other words, and to summarize all the above :

If had to use a 8 level stack RPN system with only the following stack management functions ( X<>Y, X<> , RUP and RDOWN ) , I would certainly feel deprived from so many goodies ... exactly like when I first tried a plain HP41C : 49 RAM Memories Registers( was it 49 actually ??? I do not remember .. ), while soon after I eventually discovered that its processor can address 319 RAM memories, as well as 600+ XMEM Registers, not to mention that HrastProgrammer can address over ... 3000 RAM Memory Registers in his HP41X/Y/Z Emulator.

Or, to make it short ...

Having only the " X<>Y, X<> , RUP and RDOWN " instructions to manage an 8 level or even a 6 level RPN stack would be for me like driving A PORSCHE SportsCar with only a 2 US Gallon Fuel tank,

or, even worse ...

: Flying a B777 with only a 15 Ton Fuel tank!

... Like the plain HP41C story hereabove, this can be Very Frustrating.

Best Regards

Antoine

PS : I almost never have had so much time for "entering" the Forum like I have done in the past few days. Just simply because now I am on a 3 Day Alert Status, away from home, counting grains of sand in Jeddah Saudi Arabia, and awaiting to fly my B757.

Edited: 18 Dec 2007, 1:44 p.m. after one or more responses were posted

                                                
Re: Why not a stack settable to 8 levels max.?
Message #47 Posted by Walter B on 18 Dec 2007, 12:41 p.m.,
in response to message #46 by Antoine M. CouŽtte

Salaam alejkum Antoine,

hope you enjoy the weather d:-)

Just for my understanding:

  1. All of us seem to be happy with the stack management instruction set featured on HP RPN calculators (i.e. ENTER^, x<>y, Rv, sometimes also including R^ and x<>). At least we live with it and don't complain. These calcs feature a 4 level stack.
  2. Many of us find RPL too difficult, as you do (I know that's making a long story very short, but please allow me to save some time here). These calculators feature an infinite stack and an extended (or at least different) stack management instruction set.
So somewhere between 4 and infinity, a transition from simplicity to complexity occurs. Taking your words as written, this happens suddenly between 4 and 6. Hmmmh :-/ I'd have expected this at larger numbers...

Maybe between some hands of sand you find some time to explain this strange function to me. Thanks in advance!

Salutations,

Walter

Edited to add some findings out of W.C. Wickes' book.

Edited: 18 Dec 2007, 1:12 p.m.

                                                      
Re: Why not a stack settable to 8 levels max.?
Message #48 Posted by Antoine M. CouŽtte on 18 Dec 2007, 1:33 p.m.,
in response to message #47 by Walter B

Hello Walter,

Just a quick reply, to recap my thoughts :

- 6 level or 8 level stacks are DEFINITELY much better to me than 4 level stack ( + LAST X of course ).

- A complete set of Stack Management Instructions, similar for example to the current HP48 Stack Management Instructions set, seems to me better than the " standard already existing 4 level RPN stack Instructions set " simply because it would offer more programming flexibility. Again, no one would be forced to use it to its limits.

- I have a personnal preference for 6 level RPN stack, simply because stack track keeping is easier than for 8 levels. But 6 level RPN stack holds my preference only if a complete set of RPN stack managing instructions becomes available.

- If no complete stack managing instructions set available, but just the standard one already existing to-day for 4 level RPN stack, then 8 level RPN stack seems preferable to 6 level stack. Why did I still write " seems " just hereabove ? Simply because I lack actual / real world experience to adequately compare stack operations on 6 level vs 8 level RPN stacks. Only additionnal trials can help us here. However, I feel that in this case 8 level stack would likely " win " over 6 level stack.

Now I am ending up, since I need to go flying :=)) + :-)))

Best Regards

Antoine

Edited: 18 Dec 2007, 1:55 p.m.

                        
Re: Why not a stack settable to 8 levels max.? (Re: Why not a 6 level Stack ?)
Message #49 Posted by db (martinez, ca.) on 18 Dec 2007, 9:13 p.m.,
in response to message #41 by Antoine M. CouŽtte

Antoine; I guess it doesn't really matter what you call the additional registers. However; the one five level stack RPN called them x - y - z - t - s, with s being like the T we are used to.
Just thought i'd stick my paddle in the water.

                              
Re: Why not a stack settable to 8 levels max.? (Re: Why not a 6 level Stack ?)
Message #50 Posted by Walter B on 19 Dec 2007, 2:38 a.m.,
in response to message #49 by db (martinez, ca.)

Heh, heh, "s" as in "top" :)


[ Return to Index | Top of Index ]

Go back to the main exhibit hall