Post Reply 
INPUT stack lift: 32S vs. 42S
10-11-2019, 01:49 PM
Post: #1
INPUT stack lift: 32S vs. 42S
I spent some time last night adapting the triangle solver from the 32S Engineering Applications book to my 42S, and after about an hour of trying to figure out why I was getting incorrect results, I discovered that INPUT behaves differently on the two models.

On the 32S, INPUT first recalls the variable to X, obeying the current stack lift mode. Then it disables stack lift, so the user's entry overwrites whatever was recalled to X. When entry is complete and the program continues, INPUT enables stack lift.

On the 42S, it's a bit different. INPUT recalls the variable to X, while obeying the current stack lift mode as the 32S does. But then it enables stack lift, so if the user enters a value, the old value of the variable gets pushed to Y. When INPUT is complete, it enables stack lift, as on the 32S.

Is there a clean, clever way to reconcile this difference? I'm not sure what the rationale is behind having the 42S enable stack lift so the old value gets preserved in Y (aside, perhaps, from 41C compatibility). Ideally I'd want it to behave like the 32S, where the old value in X is overwritten by the new entry. The best I could think up was something gross like checking flag 30, saving Z and/or T, calling INPUT, checking flag 22, and restoring Z/T. Is it better to just analyze the intent of the surrounding program code and modify it to accommodate the difference?

This is the code in question:

Code:
LBL E
CF 2
INPUT A
INPUT C
RCL A
RCL C
x>y?
SF 2
INPUT D
SIN
RCL/ A
*

On the 32S, the steps after INPUT D will calculate C*sin(D)/A regardless of whether a new value is entered into D. On the 42S, they end up calculating D*sin(D)/A if a new value is entered (and the RCL A certainly doesn't stay where the program subsequently expects it to be either).
Visit this user's website Find all posts by this user
Quote this message in a reply
10-11-2019, 02:01 PM
Post: #2
RE: INPUT stack lift: 32S vs. 42S
I think the 32S implements what most would consider the 'right way' to behave, if unhindered with legacy behavior, while the 42S, positioned as the 41C successor and ostensibly compatible with existing 41C code, did not have the freedom to behave logically. There are other similar issues where the 42S leans back towards 41C behavior while the 32S/32SII/33S/35S, etc. lean towards more evolved thinking.

--Bob Prosperi
Find all posts by this user
Quote this message in a reply
10-11-2019, 04:20 PM
Post: #3
RE: INPUT stack lift: 32S vs. 42S
I guess a program shouldn't really trust anything on the stack apart from X after halting for input. The user may have done some calculations (buggering up the old stack contents) before pressing R/S to continue.

— Ian Abbott
Find all posts by this user
Quote this message in a reply
10-11-2019, 04:35 PM
Post: #4
RE: INPUT stack lift: 32S vs. 42S
(10-11-2019 04:20 PM)ijabbott Wrote:  I guess a program shouldn't really trust anything on the stack apart from X after halting for input. The user may have done some calculations (buggering up the old stack contents) before pressing R/S to continue.

Yeah, that's very sound advice, though shortcuts like that are somewhat forgivable on the 32S where memory comes at a premium.
Visit this user's website Find all posts by this user
Quote this message in a reply
10-11-2019, 05:12 PM
Post: #5
RE: INPUT stack lift: 32S vs. 42S
(10-11-2019 04:20 PM)ijabbott Wrote:  I guess a program shouldn't really trust anything on the stack apart from X after halting for input. The user may have done some calculations (buggering up the old stack contents) before pressing R/S to continue.

This ^

I never rely on anything in the stack when one of my RPN programs stops for input or output. Doing otherwise means that your code ceases to be deterministic and is left in a random state if the user alters the stack while the program is stopped, thus you can't be sure what will happen once it resumes execution. Relying on stack contents while a programs is stopped is a truly bad programming practice and one the the biggest no-no in any programming book, not just mine.

Also, that's one of the strongest advantages the (SHARP, HP-71B and others) BASIC-programmabkle pocket computers had over any RPN model: you could stop the running program at most any time, do from the command line whatever manual calculations or operations you needed (of course, as long as you didn't execute commands that disrupted the program flow or program variables) and once done, simply execute CONT to resume program execution as if no interruption had ever happened.

Try that with an RPN program ! (probably RPL too, unless you do something to first back up/restore the whole stack or things like that).

Have a nice weekend.
V.
.

  
Find All My HP-related Materials here:  Valentin Albillo's HP Collection
 
Visit this user's website Find all posts by this user
Quote this message in a reply
10-15-2019, 07:35 PM
Post: #6
RE: INPUT stack lift: 32S vs. 42S
It occurred to me that the 42S behavior actually provides a feature that the 32S doesn't: the ability to press R.Down to cancel your change and revert to the original value. And if there are no menus open, you can see the old value in the Y register after you've started typing. If it's best to code defensively and never trust the stack layout after an INPUT on either model, then the 42S version is overall more flexible.
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)