Posts: 109
Threads: 38
Joined: Dec 2012
I notice on a 4 level stack, the integration function fills all of the stack levels with an initial "x". It appears that the 8 level stack does not fill all 8 levels with the initial value. By adding the "fill" command at the beginning of my instructions, the integration worked in an identical manner as the 4 stack problem (I used a rolls up in my procedure). Was the difference in behavior intentional...what is the advantage?
Thanks.
Posts: 3,229
Threads: 42
Joined: Jul 2006
The integrator fills x, y, z & t with the current value. This is regardless of stack size. It is intentional. There isn't really an advantage, although registers a, b, c & d are preserved between calls to the function so stuff can be safely placed there.
- Pauli
Posts: 4,587
Threads: 105
Joined: Jul 2005
The integration routine is based on an earlier program from a time when only 4 stack levels were available (i.e. from the dark ages before the WP 34s ;-) ). Hence ...
d:-)
Posts: 3,229
Threads: 42
Joined: Jul 2006
I can change how solve loads the stack easily enough. Is it desirable? What advantages are there for filling all eight levels?
- Pauli
Posts: 4,587
Threads: 105
Joined: Jul 2005
Well, an obvious advantage is you can benefit from top stack level repetition. But is that worth sacrificing the contents of four stack levels?
d:-/
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
What advantages are there for filling all eight levels?
If for nothing else, at least for backward compatibility with the program at page 205 of the original HP-34C manual:
Keystrokes Display
h LBL 1 001-25, 13, 1 Begin subroutine with a
LBL instruction.
f SIN 002- 14 7 Calculate sin theta.
- 003- 41 Since a value of theta will be
placed into the Y-register by
the integration algorithm before
it executes this subroutine,
the [-] operation at this point
will calculate (theta - sin theta).
f cos 004- 14 8 Calculte cos(theta - sin theta).
h RTN 005- 25 12
Gerson.
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
(i.e. from the dark ages before the WP 34s ;-) )
Or from the dark ages before 1987, when the HP-28C with stack size limited only by the available memory hadn't been introduced yet :-)
Posts: 4,587
Threads: 105
Joined: Jul 2005
Page 204 would have been even better:
"Before calling the subroutine that evaluates f(x), the [integral] algorithm - just like the [SOLVE] algorithm - places the value of x in the X-, Y, Z-, and T-registers. Because every stack register contains the x value, your subroutine can calculate with this number without having to recall it from a storage register."
That's what I meant with "an obvious advantage is you can benefit from top stack level repetition" in my post above.
d:-)
Posts: 4,587
Threads: 105
Joined: Jul 2005
Please keep RPL out of this thread :-)
Posts: 528
Threads: 40
Joined: Dec 2008
Quote:
I can change how solve loads the stack easily enough. Is it desirable? What advantages are there for filling all eight levels?
As the original poster said, the would mean that a rolldown (or rollup) in the function would work correctly regardless of stack mode.
But it seems to me that this is just a symptom of the larger issue that rolldown and rollup depend on the stack mode. It might make sense to add functions that do "roll 4" and "roll 8" so a program can be explicit about what it wants without having to change the stack mode.
Dave
Posts: 4,587
Threads: 105
Joined: Jul 2005
Quote:
... rolldown and rollup depend on the stack mode.
Not true. As can be seen on pp. 20 and 31, Rv and R^ affect all stack levels in either case. And what you call 'stack mode' is actually 'stack size', isn't it?
Quote:
It might make sense to add functions that do "roll 4" and "roll 8" so a program can be explicit about what it wants without having to change the stack mode.
I'd vote for "roll full" and "roll half" if we'd need that. The latter would equal x<>y in a 4-level stack. But I don't think these functions are required.
d:-)
Posts: 109
Threads: 38
Joined: Dec 2012
Of course, any problem/inconvenience caused by initial values only filling the first 4 stack levels would appear in the solve application on an 8 stack size.
Posts: 528
Threads: 40
Joined: Dec 2008
Hi Walter,
Quote:
Not true. As can be seen on pp. 20 and 31, Rv and R^ affect all stack levels in either case.
My point is that if you explicitly want to roll the X, Y, Z and T registers, you'd have to ensure that the stack size is 4.
Quote:
I'd vote for "roll full" and "roll half" if we'd need that. The latter would equal x<>y in a 4-level stack. But I don't think these functions are required.
"Roll full" and "roll half" might be useful, but they wouldn't solve the issue here (a program executes Rv and mistakenly assumes that the stack size is 4 instead of 8). One can certainly argue that a program that uses Rv and R^ should set the stack size ahead of time (and restore it upon exit), but I think it would be more convenient to give programmers commands to explicitly roll 4 registers or 8.
Hmm, here's something to consider, though maybe not for the 34S. What if the stack size only affected the automatic push and drop that occur with LASTx, and 1 or 2 number functions (the last 3 columns on page 20). ENTER, FILL, DROP, Rv and R^ would have 4- and 8- register versions. In fact, there would be ONLY the 4- and 8-register versions of the commands (e.g., ENTER4 and ENTER8, but no ENTER). Pressing the ENTER, Rv or R^ keys would execute either the 4- or 8-register version of the command, depending on the current stack size.
The idea behind this would be to minimize the chances of programming errors related to assuming a particular stack size, while still maintaining the advantages of two possible stack sizes.
Dave
Posts: 109
Threads: 38
Joined: Dec 2012
I was perhaps naively thinking that the filling of the x,y,z,t stack levels with x was a quirk of the solve and integration applications alone. If so, a fix i.e., incorporating a proper "fill" into the start of those routines would be necessary for just those 2 items? Otherwise, as long as the user is aware (put it in the manual just like the instructions for using radians were given for complex # functions), it certainly is easy for me to include the fill command in my use of solve and integrate.
Posts: 4,587
Threads: 105
Joined: Jul 2005
It affects more than just SLV and [integrate] ... f', f", [Pi], and [Sigma] are also touched. Anyway, it's in now - any such command will fill the complete stack with x before calling the user function.
d:-)
Posts: 4,587
Threads: 105
Joined: Jul 2005
Hi David,
WP 34S is a single-user system. I sincerely hope the user knows what stack size (s)he set (psst: find out with SSIZE?). So I won't do any extra gymnastics for people being ... ummh ... memory-challenged. KISS, although YMMV.
d;-)
Posts: 3,283
Threads: 104
Joined: Jul 2005
Quote:
My point is that if you explicitly want to roll the X, Y, Z and T registers, you'd have to ensure that the stack size is 4.
The shuffle command [<->] is designed for this:
R^4 is [<->] TXYZ
Rv4 is [<->] YZTX
We had a discussion about extending the command to eight registers but this will not easily fit in the internal command structure. So you will have to be content with four stack registers by now.
Edited: 18 Feb 2013, 4:43 p.m.
|