INPUT stack lift: 32S vs. 42S

[Dave Britten]

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

[rprosperi]

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.

[ijabbott]

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.

[Dave Britten]

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

[Valentin Albillo]

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

[Dave Britten]

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.

[Thomas Okken]

(10-11-2019 02:01 PM)rprosperi Wrote:  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.

When it comes to the behavior of INPUT on the 42S, 41C compatibility was not a concern, though, since that function does not exist in the 41C (nor in the X Functions module, from which the 42S borrowed a few functions as well). And the 42S designers were not afraid to deviate from 41C conventions when it made sense, most noticeably in the behavior of COMPLEX, where you enter <re> ENTER <im> COMPLEX, while the behavior of Σ+ might lead you to expect that you'd have to enter <im> ENTER <re> COMPLEX.

I think the behavior of INPUT makes sense in its own right, because it makes it easy to modify the existing value of the variable; getting pushed into Y means you can perform calculations on the original value without any preliminaries.

[Dave Britten]

(10-19-2019 09:39 PM)Thomas Okken Wrote:  I think the behavior of INPUT makes sense in its own right, because it makes it easy to modify the existing value of the variable; getting pushed into Y means you can perform calculations on the original value without any preliminaries.

Ah yeah, that's an excellent point. Which makes it all the weirder that EDIT on a matrix doesn't behave this way! New entries overwrite X, and you need an ENTER first to operate on an element. Maybe it was easier to disable stack lift outright while editing, so the arrow keys wouldn't push the stack every time you moved through the matrix.

[rprosperi]

(10-19-2019 09:39 PM)Thomas Okken Wrote:  I think the behavior of INPUT makes sense in its own right, because it makes it easy to modify the existing value of the variable; getting pushed into Y means you can perform calculations on the original value without any preliminaries.

That's a good point. When exploring different inputs, performing some operations on the default value that INPUT provides is much easier this way. And I honestly have been using a DM42/42S for so long to write '41 programs', I've forgotten the 41 didn't have INPUT, it just got by with 'String' PROMPT. How quaint...

But one can see that the 32S approach is easier to initially grasp (not requiring subtle knowledge of things like stack-lift enable, etc.) and explain, so I presume they went that way as part of the overall simplifying that seemed to be happening with the HP-3xS series.

I incorrectly thought that the 32S came out after the 42S, but in fact it was 4 months earlier, so these 2 machines were being developed in parallel, both on the same SysRPL platform, so it is interesting that they chose to go 2 separate ways for this behavior.

[Thomas Okken]

(10-20-2019 01:46 AM)rprosperi Wrote:  I honestly have been using a DM42/42S for so long to write '41 programs', I've forgotten the 41 didn't have INPUT, it just got by with 'String' PROMPT. How quaint...

[...]

I incorrectly thought that the 32S came out after the 42S, but in fact it was 4 months earlier, so these 2 machines were being developed in parallel, both on the same SysRPL platform, so it is interesting that they chose to go 2 separate ways for this behavior.

Ha, yes, I have to play around with i41CX every now and then to refresh my memory. I think the last time I used an actual 41 was in the previous century.

Regarding divergent behaviors, even within the 42S things aren't consistent, with INPUT enabling stack lift but the matrix editor's cell movement commands disabling it, and the initial cell in EDIT and EDITN getting whatever stack lift state was in effect when the function was called. That last one has to be a bug, but the difference between the other two is interesting. There is so much functionality in the 42S, coding all that must have been a team effort, so are those differences deliberate, or was it just a matter of different programmers making different choices sometimes and not coordinating with each other? I'd love to have a chat with the 42S designers and get them talking about what that whole process was like.