X, Y Z & T--should there have been more?



#22

Hello all.

In light of a few things: the 34S development with its 8-register stack option, the long-standing established configuration of a 4-level RPN stack and the numerous ways which stack manipulations have been brainstormed and designed, I am wondering why four levels and not a five or even six register depth was implemented to begin with. This conundrum occurred to me after reading Palmer Hansen's 'HP Algebraic' article in the Jan 2011 edition of 'HP Solve' The reason I ask, in Example 2 on page 6, with the expression:

[ (3 + 1) (4 + 3) + (2 + 6) (4 + 6) ] / [ (2 + 3) (2 + 1) + (3 + 5)(4 + 2) ] = 108/63

is given an RPN algorithm which is quite elaborate and requires some twisting around because there are more intermediate results to work through (including handling the denominator initially):

2 ENTER 3 + 2 ENTER 1 + x 3 ENTER 5 + 4 ENTER 2 + x + 3 ENTER 1 + 4 ENTER 3 + x 2 ENTER 6 + RollDown x<>y / RollDown / x<>y RollDown 4 ENTER 6 + x +

I would've expected equation rearrangement from an Algebraic or AOS calculator and RPN is much more a natural problem solving approach. Two questions though: 1--are real-world formulas and mathematical expressions as complex as this one that require unintuitive rearrangement for RPN problem solving and 2--my original Q, would a stack size greater than four have been more efficient, versatile and sensible?

Thanks


Edited: 25 June 2012, 8:01 p.m.


#23

The four level stack is almost certainly a result of the hardware restrictions at the time. The 35 even stole T for some functions -- this indicates a severe lack of memory to me.

Of course a larger stack size is more versatile, although it is difficult to keep track of what is where on an eight level stack -- to the extent that I treat it as effectively unlimited.


- Pauli


#24

Some of the same thoughts were running through my mind--memory costs, practicality of tracking multuple levels as well as the fact that the T-register was the bargaining chip for transcendentals. Thanks. At least I known I'm on the right track.

#25

Quote:
The 35 even stole T for some functions

And other early models stole some numbered user registers for temporaries for trig functions and such. Memory was *very* expensive in the early to mid 1970s.

I claim that choosing a reasonable trade-off is the essence of good engineering. When there aren't competing requirements, any idiot can do the design work, and it isn't called engineering.

The four level stack was a compromise between frugality and functionality. The earlier 9100 had a three-level stack that didn't work quite the same way, and was clearly too small. The four-level stack was big enough to solve many (most?) problems. Also, operations like roll-down and roll-up aren't too useful when the stack has a lot of levels. Same with T-replication.

I think they made a good choice.


#26

If I remember correctly, the 65 held R9 instead of the T-register hostage for transcendentals. I think there were other functions that the 65 used R9 for. Wasn't R9 used as the Last X register in the 65? Refresh my memory, what memory compromises were the 45 and 55 subject to?

Edited: 25 June 2012, 8:33 p.m.

#27

I suspect the four levels are from when calculators were not programmable, and you had to remember what's on each level. Once you get into programming and subroutines and passing parameters on the stack, each subroutine call normally concerns itself with just a few levels or less; but if you're nested several subroutines deep, the stack requirement could be 10 or 15 levels without the programmer ever having to concern himself with even four at a time. Yes, memory was expensive; but a deeper stack greatly reduces the need for variables and also reduces the conflicts regarding what registers to store the variables in.


#28

However,writing a program to use many stack levels, rather than named variables or set registers, can be very confusing and error prone.


#29

Even using the (infinite) stack only for subroutine return addresses and similar local stuff requires very good housekeeping ...

#30

Quote:
However,writing a program to use many stack levels, rather than named variables or set registers, can be very confusing and error prone.
Quite the contrary, because each subroutine is treated as its own program, and these usually max out at two or three levels. It doesn't matter to that program (or to you when you're writing it) whether there are six things below that (or above, in the case of HP's upside down stack) or a thousand. The information-hiding works out perfectly, and it reduces errors. It works especially well for recursive routines or any time you want the routine to have its own environment. You can't get much of a taste of that if you're limited to four levels.

I quit looking for more languages 20 years ago when I found Forth, partly because of its data stack which appears practically infinite in depth, although a test showed that the heaviest application I could think of, with loads of interrupts going at the same time which were also serviced in Forth, did not even reach 25 levels. Program development time plummetted as did the bugs. I mostly use it to control hardware, and Forth made the program development rather trivial so I could shift my attention to debugging the hardware. It was a breath of fresh air.

#31

The real problem with the four level stack mechanism with most HP RPN machines is NOT the necessity to store an intermediate result in some cases, but rather the necessity to even recognize that the intermediate result must be stored before it is pushed up and off the stack.

Typical algebraic mechanizations have a similar problem with limitations on the number of permissible sets of parentheses but with an important difference. The algebraic mechanizations tell the user when he has exceeded the limit.


#32

This sounds VERY familiar. I think this was the point brought up in your article. Thanks for the refresh.


#33

The Heathkit Aircraft Navigation Computer (OC-1401 and the factory assembled variant, the OCW) had a 5 level stack with a replicating T ("S" in this case) register. You can find the instructions on stack manipulation beginning on page 74 of the Heathkit Manual on Katie's site .
It may have needed the extra register for some in-flight or navigation function, or might have just been easier to keep track of all the variables that way. They could have only wanted to out-hp hp too.
Whatever their reasoning; they did a dam fine job and clearly picked the best parts available from at least four suppliers. The only thing it was missing was injection molded key tops.


Walter and i were posting at the same time. Read his for a glimpse at some of the reasoning that might have gone into the Heathkit 5 level stack.

Edited: 26 June 2012, 12:56 a.m.

#34

Quote:
The real problem with the four level stack mechanism with most HP RPN machines is NOT the necessity to store an intermediate result in some cases, but rather the necessity to even recognize that the intermediate result must be stored before it is pushed up and off the stack.

Exactly that was my main reason for promoting the eight-level stack for the WP 34S: for an arbitrary real-world formula you can treat it as being unlimited (compare Pauli's posting above). A four-level stack, OTOH, was sufficient for almost every real-world formula - but the problem was this "almost", forcing you to keep track of the stack level contents mentally. And four levels - although a number given by hardware limitations in the seventies as mentioned above - are also a limit for the human brain in such tracking (not a hard one, of course).

#35

Your last sentence makes me wonder. If keeping track of items in an 8-register stack is challenging, could the 34S be designed to allow for a user-defined stack depth of 4, 5, 6, 7 or 8 levels? That way, the user can select just the right stack complexity so that the stack is easier to keep track of.

#36

I did some design work on a CPU that used eight, eight deep stacks. Operations could occur within a stack or between the tops of stacks, with push or write stores and read or pop value use. When a stack got full, the bottom four members might get written to memory automagicly (and they'd get loaded if the bottom four became empty.)

(It didn't get made.) Lots of simulations showed that four deep was enough to avoid frequent pushing and popping of the low half of the stack, with the rather simple optimizing compiler tending to use one stack as a stack and a second stack as a source of two or three saved results that were frequently used more than once in a calculation.

In decades of RPN programming, I've sometimes wanted a fifth or sixth, and wished that eight registers were allocated to the stack -- LxLyXYZABT. Much more frequently, I've wanted to push the stack for a subroutine, and pop it on return, having stored new values where I wanted them as returned values.

#37

You can see here 2 advantages of the 48/50 big screen and RPL

1/You see all the stack levels. It is very visual
2/No limitation of level

3
1
+

4
3
+

*

2
6
+

4
6
+

*

+

2
3
+

2
1
+

*

3
5
+

4
2
+

*

+

/


#38

You are right Gilles, that's make RPL much easy to use and to trackback what operation we push into!

Even an of simple HP28C/S, the relatively small graphic display makes all the stuff to be key-in easy. No one have to worry about stack depth or memory or 'what is in the stack' at each step. Just have to quick watch stack to reconize numerator, denominators, intermediate result or last operation intermediate result !


For a better illustration of the process, I post the step by step captures of my HP28S display.

[f][CLEAR]   |4:                      |
|3: |
|2: |
|1: |

[3][ENTER] |4: |
|3: |
|2: |
|1: 3|

[1] |3: |
|2: |
|1: |
|1_ |

[+] |4: |
|3: |
|2: |
|1: 4|

[4][ENTER] |4: |
[3][+] |3: |
|2: 4|
|1: 7|

[*] |4: |
|3: |
|2: |
|1: 28|

[2][,][6][+] |4: |
|3: |
|2: 28|
|1: 8|

[4][ENTER] |4: 28|
|3: 8|
|2: 10|
|1: 4|

/4:\\\\\\\\\\\\\\\\\\\\28/ (*) Not show on HP28C/S display only
[6] |3: 8|
|2: 10|
|1: 4|
|6_ |

|4: |
[+] |3: 28|
|2: 8|
|1: 10|

[*] |4: |
|3: |
|2: 28|
|1: 80|

[+] |4: |
|3: |
|2: |
|1: 108|

[2][,][3][+] |4: |
|3: |
|2: 108|
|1: 5|

[2][,][1][+] |4: |
|3: 108|
|2: 5|
|1: 3|

[*] |4: |
|3: |
|2: 108|
|1: 15|

[3][,][5][+] |4: |
|3: 108|
|2: 15|
|1: 8|

[4][,][2][+] |4: 108|
|3: 15|
|2: 8|
|1: 6|

[*] |4: |
|3: 108|
|2: 15|
|1: 48|

[+] |4: |
|3: |
|2: 108|
|1: 63|

[/] |4: |
|3: |
|2: |
|1: 1.71428571429|

Note that after a few entries, I no more use the [ENTER] key, as du to long use of the HP28S keyboard, I prefer using the comma ( [,] key) or space ( [SPACE] key) to separate numbers for immediate operation.
I use to do this ‘immediate operation’ style entry as my current way to enter and think about keying, that in the first watch of the problem, I have not understand that this formula is a problem on 4 stacks level limited RPN calculators.
During the ‘immediate computation’, the arguments are push during the transitory process into the stack, but this is not display. That makes me believe that only 4 stack levels are mandatory. In fact a bit more! To clearly illustrate the need of quite 6 level, I may have intentionally put on extra [ENTER] pushes (i.e [4][ENTER][6][ENTER][+] )

But making this, I will have point out the painful unlatching behavior of the command entry line systems (RPL, HP30S, etc…) compare to truly RPN stack entry system (real RPN stack behavior) !

Edited: 26 June 2012, 4:56 a.m.


#39

Gosh - two looong postings :-/

Let's make it a bit shorter and easier:

[ (3 + 1) (4 + 3) + (2 + 6) (4 + 6) ] / [ (2 + 3) (2 + 1) + (3 + 5)(4 + 2) ] = 108/63 will go like this:

3 ENTER 1 + 4 ENTER 3 + * 2 ENTER 6 + 4 ENTER 6 + * + (that's the numerator)

2 ENTER 3 + 2 ENTER 1 + * 3 ENTER 5 + 4 ENTER 2 + * + (that's the denominator)

/ d/c (returns 12/7 as expected).

Done this way on the WP 34S with SSIZE8, of course :-) Think it uses five levels at peak - but who cares anymore and why?

Edited: 26 June 2012, 8:22 a.m.


#40

Yep, that's five levels. +*+/ for operaritons -> five stack levels :)

#41

Quote:
Think it uses five levels at peak - but who cares anymore and why?

Right!


Nowaday nobody worry about that ! The only to worry about is to use the right device that ready for complex computations !

#42

Quote:
Hello all.

In light of a few things: the 34S development with its 8-register stack option, the long-standing established configuration of a 4-level RPN stack and the numerous ways which stack manipulations have been brainstormed and designed, I am wondering why four levels and not a five or even six register depth was implemented to begin with. This conundrum occurred to me after reading Palmer Hansen's 'HP Algebraic' article in the Jan 2011 edition of 'HP Solve' The reason I ask, in Example 2 on page 6, with the expression:

[ (3 + 1) (4 + 3) + (2 + 6) (4 + 6) ] / [ (2 + 3) (2 + 1) + (3 + 5)(4 + 2) ] = 108/63

is given an RPN algorithm which is quite elaborate and requires some twisting around because there are more intermediate results to work through (including handling the denominator initially):

2 ENTER 3 + 2 ENTER 1 + x 3 ENTER 5 + 4 ENTER 2 + x + 3 ENTER 1 + 4 ENTER 3 + x 2 ENTER 6 + RollDown x<>y / RollDown / x<>y RollDown 4 ENTER 6 + x +

I would've expected equation rearrangement from an Algebraic or AOS calculator and RPN is much more a natural problem solving approach. Two questions though: 1--are real-world formulas and mathematical expressions as complex as this one that require unintuitive rearrangement for RPN problem solving and 2--my original Q, would a stack size greater than four have been more efficient, versatile and sensible?

Thanks



Memory is always good in my book. When I am working with a four level I try to keep that in mind . I aim to use 3 or less most of the time and it works out.


Possibly Related Threads…
Thread Author Replies Views Last Post
  Op-Amp Gain and Offset Design for the HP-67 Stefan Vorkoetter 6 2,253 12-05-2008, 10:57 AM
Last Post: Tom Mathes
  AMP Rom for 71b PeterP 5 2,005 12-06-2007, 02:20 PM
Last Post: PeterP

Forum Jump: