HP 34S integration



#18

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.


#19

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

#20

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


#21

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


#22

Please keep RPL out of this thread :-)

#23

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


- Pauli


#24

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

#25

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.

#26

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

#27

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


#28

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


#29

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.

#30

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


#31

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.


#32

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

#33

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

#34

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.


Possibly Related Threads...
Thread Author Replies Views Last Post
  Integration question and "RPN" mode comment Craig Thomas 16 2,009 12-05-2013, 02:32 AM
Last Post: Nick_S
  WP34s integration trapped in infinite loop Bernd Grubert 25 2,115 10-17-2013, 08:50 AM
Last Post: Dieter
  HP Prime integration Richard Berler 1 398 10-06-2013, 10:52 PM
Last Post: Helge Gabert
  integration on 39gII emulator Wes Loewer 29 2,354 06-07-2013, 05:58 PM
Last Post: Chris Smith
  WP-34S Integration Richard Berler 15 1,348 03-08-2013, 02:29 AM
Last Post: Walter B
  [WP34S] Speeding up the Romberg Integration Les Wright 14 1,095 05-31-2012, 03:39 PM
Last Post: Marcus von Cube, Germany
  New variant for the Romberg Integration Method Namir 8 851 04-18-2012, 07:47 AM
Last Post: Nick_S
  Romberg Integration for 33s, 35s Matt Agajanian 9 845 03-26-2012, 10:00 AM
Last Post: Nick_S
  HP 32sII Integration Error of Standard Normal Curve Anthony (USA) 4 547 03-14-2012, 03:18 AM
Last Post: Nick_S
  accuracy of integration and solve routines HP 15C LE Jan 3 418 02-02-2012, 01:03 PM
Last Post: Marcus von Cube, Germany

Forum Jump: