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.

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

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

I can change how solve loads the stack easily enough. Is it desirable? What advantages are there for filling all eight levels?

- Pauli

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:-/

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.

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

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

Please keep RPL out of this thread :-)

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

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

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.

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

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.

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

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

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