Larger stack size

12282020, 06:10 PM
Post: #1




Larger stack size
Was there ever any discussion within (or outside) HP about increasing the stack size, prior to the change to RPL with its effectively unlimited stack? In the TI59/58 manual, "Personal Programming", they give the  admittedly contrived  example that can be evaluated left to right with that model's large AOS stack:
(((2x(2x(2x(2x(2x(2+2^(2+.2))(2+2))))))/2)/2) On my 58C, I can just plow through this left to right and come up with 36.76, whereas the 4level RPN stack necessitates dissecting a formula like this and working from the inside out. There is definitely more thought required in evaluating this on a 15C, for example. Did HP ever consider increasing the stack size beyond 4, or did they figure that mentally tracking that many parentheses and carrying out the pending operations manually is no more efficient/easy than working the equation inside out? I've never seen any mention of this in the PPC Journals I've read, but it seems like the sort of thing that would have been a useful salvo in the HP/TI wars. 

12282020, 06:38 PM
(This post was last modified: 12282020 06:41 PM by hth.)
Post: #2




RE: Larger stack size
I think contrived is the word, possibly also "perfectly presented to suit the particular key entry model".
I used the HP41 for years in school and the "real world", solving all kind of problems including math problems and engineering caluclations. Once you learn how to do it, it was just natural and easy. I never had any problems with the 4level stack. Well, once or twice perhaps, but then I just knew it and used a storage register to assist. Two things are worth mentioning though. Today I find the 4level stack somewhat more limiting than I did back then. I think I got spoiled by RPL and computers and now find it a little bit more of a struggle from time to time. Back then (when I did it all the time), not at all. Second, I remember one time back in school sitting next to a friend who had a TI58C (he later got a HP15C). He was not much into HP early on, but gradually shifted over to the thinking model of it. We had a quite elaborate and tricky math problem to key and we both tried it on both machines. We both failed doing it on the TI, but we both got it right on the HP41. I think the reason was that you were more involved in solving the problem on the HP and could do it gradually, while on the TI model you just had to key and prey that you did everything right. Problems were not always written out the way you keyed them in on the TI either. Often it was shown as a math formula so there was some mapping to a keyed in calculation on both machines. On the TI you had no idea what was going on, while on the HP model you got intermediate results that were easy to understand and confirmed that you were doing it right, step by step. 

12282020, 07:37 PM
Post: #3




RE: Larger stack size
Since there are all twos it's quite simple to do the calculation filling the stack and doing the math:
Code: LBL "TWO" Greetings, Massimo +×÷ ↔ left is right and right is wrong 

12282020, 07:58 PM
Post: #4




RE: Larger stack size
(12282020 06:38 PM)hth Wrote: I think contrived is the word, possibly also "perfectly presented to suit the particular key entry model". Yeah, this example is obviously quite contrived, but I'm sure we've all run into at least one formula where naively diving in at the left will overflow the stack. I don't know that an 8level stack to match the TI would have made any practical sense, but an extra level or two would have been welcome, and I know I've run into plenty of situations where I have to try really hard not to lose something off the top when writing a program. I'm just surprised I've not seen any talk of it newsletters or literature from the era. On the TI, I think the bigger risk of plugging in a whole formula is not so much that you aren't seeing the intermediate results quite like you are with RPN, but rather you're at the mercy of the crummy keyboard not sabotaging your efforts with a bounce that goes unnoticed. (In fairness, my 58C actually has a pretty good keyboard, only requiring an occasional second/harder press on the D key.) 

12282020, 11:22 PM
Post: #5




RE: Larger stack size
(12282020 06:10 PM)Dave Britten Wrote: Was there ever any discussion within (or outside) HP about increasing the stack size, prior to the change to RPL with its effectively unlimited stack? No idea. :) An alternative to increasing the stack size would have been to introduce some sort of warning indicator if the stack overflowed  which was the subject of Hans Klaver's excellent presentation at Allschwil 2018. He even created a modified HP35 simulator so you can see it in action for yourselves. 

12282020, 11:43 PM
Post: #6




RE: Larger stack size
IMHO this is an artificial limitation as you can manually save stack values to storage memory or use a small program that automatically save/recall stack values to/from storage memory, like SM & MS routines from the PPC ROM.


12292020, 12:36 AM
(This post was last modified: 12292020 12:48 AM by Peet.)
Post: #7




RE: Larger stack size
on the HP41 you can do it like on paper (needs only 3 stack level):
2 ENTER ,2+ 2 x<>y y^x 2+ 2* 2 ENTER 2+  2* 2* 2* 2* 2/ 2/ result: 36,75834735 there are many more keystrokes and sources of error in the AOS input and worst, you don't even see if you made a mistake. I never had an AOS Calculator an I am curious, how do you solve this with AOS? (((2x(2x(2x(2xSIN(2x(2+2^(2+.2))(2+2))))))/2)/2) 

12292020, 01:14 AM
Post: #8




RE: Larger stack size
PPC Journal had an article at one point, titled "Do we need a five level stack?" that looked into problems from an RPN standpoint where a five level stack would be easier.
Sadly, my quick search did not find it. Perhaps someone can find it and pull out a PDF / image of the article ... ? Gene 

12292020, 02:52 AM
(This post was last modified: 12292020 03:03 AM by Valentin Albillo.)
Post: #9




RE: Larger stack size
(12282020 06:10 PM)Dave Britten Wrote: Was there ever any discussion within (or outside) HP about increasing the stack size, prior to the change to RPL [...] Don't know about HP but fans have discussed this to death, for instance here Quote:In the TI59/58 manual, "Personal Programming", they give the  admittedly contrived  example that can be evaluated left to right with that model's large AOS stack: That example and all such contraptions is but garbage and proves nothing. As for the >4 levels RPN stack, I've been using RPN for love and for money for 45 years as of 2020 and written more RPN complex programs than most of you, if not all, and I've never ever ever needed or felt the need for a >= 5level stack, nor once, quite the contrary. If in doubt, have a look at my recently published RPN program for the RPN HP42S. PZER, which finds all complex roots of a, say, 100thdegree complexcoeff. polynomial without ever needing or wanting 5 or more levels. Matter of fact, it won't run in such an "enhanced" stack. Regards. V. All My Articles & other Materials here: Valentin Albillo's HP Collection 

12292020, 03:37 AM
Post: #10




RE: Larger stack size
(12292020 01:14 AM)Gene Wrote: PPC Journal had an article at one point, titled "Do we need a five level stack?" that looked into problems from an RPN standpoint where a five level stack would be easier. I'll have to dig around the article indexes and see if I can find it. Maybe there are some more realistic examples than the totally absurd one that TI gives. Maxing out the huge AOS pending operation stack on the 59/58 is a real stretch for any practical applications, but there could obviously some value and convenience in expanding the 4level RPN stack, even just a little bit. Otherwise HP wouldn't have used an "unlimited" stack on the 28/48 families, and we wouldn't have the optional 8level stack on the WP34S firmware. Anyway, 4 generally works just fine, but a little added convenience is always nice, and I'm surprised I haven't seen more discussion of this throughout the years. 

12292020, 08:46 AM
(This post was last modified: 12292020 08:51 AM by Peet.)
Post: #11




RE: Larger stack size
(12292020 02:52 AM)Valentin Albillo Wrote: That example and all such contraptions is but garbage and proves nothing. Like you, I never saw a realistic example where more than 4 levels would have been helpful. I don't even know a constructed one. I don't understand the example above. Even on this construct you need only 3 Stack Level  how does it show the need for more then 4? Why should it be more convenient to have more than 4 StackLevel? Wouldn't it be like having more than 10 numbers for the decimal system? 

12292020, 08:54 AM
Post: #12




RE: Larger stack size
The WP 34S allows either four or eight level stack. The latter is good for complex operations (because it doesn't support complex numbers natively and uses two stack levels for each). I've written programmes that needed more than four levels (five was the maximum I think) but for normal operation, four is sufficient.
Still, I'm getting older and my short term memory isn't what it used to be. Pauli 

12292020, 12:18 PM
(This post was last modified: 12292020 12:19 PM by RMollov.)
Post: #13




RE: Larger stack size
I look at the four level stack as a “golden ratio” for calculators at the point of time they were dominant. Long gone now.


12292020, 01:50 PM
Post: #14




RE: Larger stack size
And here are the two blurbs from the PPC Calculator Journal. Dropbox link, so someone please grab this and put it somewhere less transient.
PPCCJ V4N9 and V5N1  Do we need a five level stack? 

12292020, 04:20 PM
Post: #15




RE: Larger stack size
(12292020 01:50 PM)Gene Wrote: And here are the two blurbs from the PPC Calculator Journal. Dropbox link, so someone please grab this and put it somewhere less transient. Thanks! Time for a little morning distraction. 

12292020, 04:41 PM
Post: #16




RE: Larger stack size
(12292020 01:14 AM)Gene Wrote: PPC Journal had an article at one point, titled "Do we need a five level stack?" that looked into problems from an RPN standpoint where a five level stack would be easier. Before it produced the Altair 8800, MITS had a scientific calculator with a sevenlevel stack. It also had an optional standalone programming unit you could connect to it that worked in octal. MITS 7440 Scientific Calculator Tom L Cui bono? 

12292020, 04:47 PM
Post: #17




RE: Larger stack size
of course one could equally claim the example in this PPC article:
\( 2^{1.8^{1.6^{1.4^{1.2}}}} \) is contrived in the same manner, since it can be trivially entered in a 2level stack while preserving the (preoperation) X and Y Registers (moved to T,Z, and Y) with the final result in X. Code:
17bii  32s  32sii  41c  41cv  41cx  42s  48g  48g+  48gx  50g  30b 

12292020, 04:59 PM
Post: #18




RE: Larger stack size
(12292020 04:47 PM)Allen Wrote: of course one could equally claim the example in this PPC article: Wrong. Yout code above does not compute correctly that tower of exponentials. V. All My Articles & other Materials here: Valentin Albillo's HP Collection 

12292020, 05:23 PM
Post: #19




RE: Larger stack size
Bigger picture IMO is that most of these types of problems are contrived. They are unlikely to reflect "real life" situations and are laid out to showcase a weakness in an OS or operating approach.
So a 4 level RPN stack works for nearly anything as long as you can store values into registers if needed. An AOS approach works for nearly everything (having a "real life" problem with more than 8 pending operations would be awful)... And an EOS approach works for everything (pretty much  I suppose you could run out of ram typing it in). :) 

12292020, 05:56 PM
(This post was last modified: 12292020 06:01 PM by Allen.)
Post: #20




RE: Larger stack size
(12292020 04:59 PM)Valentin Albillo Wrote: Wrong. Yout code above does not compute correctly that tower of exponentials. Symbolically it does. In python it's off by the trailing digit, but the same could be true of either implementation on different calculators with different accuracy. Code:
I would suggest that on a pocket calculator \( 2^{1.8*1.6*1.4*1.2} \) is the better approach since there is only 1 opportunity to cascade floating point errors, rather than the nested exponential which propagates any roundoff error from the first EXP several times before arriving at the final result. 17bii  32s  32sii  41c  41cv  41cx  42s  48g  48g+  48gx  50g  30b 

« Next Oldest  Next Newest »

User(s) browsing this thread: 1 Guest(s)