Larger stack size

[Dave Britten]

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 TI-59/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 4-level 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.

[hth]

I think contrived is the word, possibly also "perfectly presented to suit the particular key entry model".

I used the HP-41 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 4-level 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 4-level 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 TI-58C (he later got a HP-15C). 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 HP-41. 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.

[Massimo Gnerucci]

Since there are all twos it's quite simple to do the calculation filling the stack and doing the math:

Code:

LBL "TWO"
2
ENTER
ENTER
ENTER
10
/
+
Y^X
+
*
X<>Y
ENTER
+
-
*
*
*
*
X<>Y
/
X<>Y
/
END

[Dave Britten]

(12-28-2020 06:38 PM)hth Wrote:  I think contrived is the word, possibly also "perfectly presented to suit the particular key entry model".

I used the HP-41 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 4-level 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 4-level 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 TI-58C (he later got a HP-15C). 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 HP-41. 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.

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 8-level 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.)

[BruceH]

(12-28-2020 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 HP-35 simulator so you can see it in action for yourselves.

[Sylvain Cote]

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.

[Peet]

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)

[Gene]

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

[Valentin Albillo]

(12-28-2020 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 TI-59/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)

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 >= 5-level stack, nor once, quite the contrary.

If in doubt, have a look at my recently published RPN program for the RPN HP-42S. PZER, which finds all complex roots of a, say, 100th-degree complex-coeff. polynomial without ever needing or wanting 5 or more levels. Matter of fact, it won't run in such an "enhanced" stack.

Regards.
V.

[Dave Britten]

(12-29-2020 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.

Sadly, my quick search did not find it. Perhaps someone can find it and pull out a PDF / image of the article ... ?

Gene

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 4-level 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 8-level 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.

[Peet]

(12-29-2020 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 Stack-Level? Wouldn't it be like having more than 10 numbers for the decimal system?

[Paul Dale]

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

[RMollov]

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

[Gene]

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?

[Dave Britten]

(12-29-2020 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.

PPCCJ V4N9 and V5N1 - Do we need a five level stack?

Thanks! Time for a little morning distraction.

[toml_12953]

(12-29-2020 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.

Sadly, my quick search did not find it. Perhaps someone can find it and pull out a PDF / image of the article ... ?

Gene

Before it produced the Altair 8800, MITS had a scientific calculator with a seven-level stack. It also had an optional standalone programming unit you could connect to it that worked in octal.

MITS 7440 Scientific Calculator

[Allen]

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 2-level stack while preserving the (pre-operation) X and Y Registers (moved to T,Z, and Y) with the final result in X.

Code:


1.8
ENTER
1.6
*
1.4
*
1.2
*
2
x<>y
y^x

[Valentin Albillo]

(12-29-2020 04:47 PM)Allen Wrote:  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 2-level stack while preserving the (pre-operation) X and Y Registers (moved to T,Z, and Y) with the final result in X.

(code)
1.8
ENTER
1.6
*
1.4
*
1.2
*
2
x<>y
y^x
(/code)

Wrong. Yout code above does not compute correctly that tower of exponentials.

V.

[Gene]

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

:-)

[Allen]

(12-29-2020 04:59 PM)Valentin Albillo Wrote:  Wrong. Yout code above does not compute correctly that tower of exponentials.
V.

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:


pow(pow(pow(pow(2,1.8),1.6),1.4),1.2)
Out[124]: 28.609056210554545

pow(2,1.8*1.6*1.4*1.2)
Out[125]: 28.60905621055455

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 round-off error from the first EXP several times before arriving at the final result.