INPUT command lifts stack

Post here to share useful tips and tricks, to ask questions about using your DM42 or to report software-related problems
User avatar
pica
Posts: 20
Joined: Fri Mar 30, 2018 9:36 am
Location: eSwatini

INPUT command lifts stack

Post by pica » Wed Apr 18, 2018 3:34 pm

This is a similar issue to a previous post about the first entry into a matrix, but affects the INPUT command.
I first noticed on my DM42, but the problem is the same on my android free42. Both version 2.0.20
When issuing an INPUT command in a program, say INPUT N, the number in variable N is called to the X-register.
Then, when I input a new value for N, the stack lifts, with the old N value. The following command will then operate on the old and new N values, instead of the value initially on the X-register. To demonstrate:

First create the variable N

7
STO N
CLST

Now the problem will be clear in this program:

LBL TST
5
INPUT N (input any random number, say 10)
+
END

The answer will be 17 instead of 15
If this is the expected behaviour, it is irritating and unintuitive.
The original HP42s manual is not clear on this detail.

User avatar
ijabbott
Posts: 99
Joined: Fri Dec 15, 2017 1:34 pm
Location: Manchester, UK

Re: INPUT command lifts stack

Post by ijabbott » Wed Apr 18, 2018 3:57 pm

I don't know what the real HP-42S does, although the manual does not list INPUT as one of the commands that disables stack lift. Pragmatically, it is probably unwise for a program to rely on the the T, Z, Y stack contents after an INPUT, as the user might have messed around with the stack contents to calculate a suitable input value.

Thomas Okken
Posts: 486
Joined: Tue May 02, 2017 3:48 pm
Location: New Jersey, USA
Contact:

Re: INPUT command lifts stack

Post by Thomas Okken » Wed Apr 18, 2018 4:07 pm

This behavior matches the real HP-42S.

The function index, page 320, says:
Recalls a register or variable to the X-register, displays the name of the register or variable along with the contents of the X-register, and halts program execution; pressing [R/S] (or [Shift] [SST]) stores x into the register or variable; pressing [EXIT] cancels. (Used only in programs.)
There's no mention of stack lift there, and since enabling stack lift is the default behavior, there's no reason I can see why you would expect it to behave otherwise.

0xdeadbeef
Posts: 3
Joined: Tue Mar 27, 2018 10:38 pm

Re: INPUT command lifts stack

Post by 0xdeadbeef » Wed Apr 18, 2018 4:27 pm

For the protocol: with my 42S, the result is 15 when I enter 10 (followed by R/S).
Same for the HP 35S btw.

Thomas Okken
Posts: 486
Joined: Tue May 02, 2017 3:48 pm
Location: New Jersey, USA
Contact:

Re: INPUT command lifts stack

Post by Thomas Okken » Wed Apr 18, 2018 6:59 pm

Not on my 42S, rev. C.

What are the exact keystrokes you're using? I entered the program LBL "TST" 5 INPUT "N" + END, as above, and then did XEQ "TST" 10 R/S. The result is 10 plus whatever was in N before, or 10 (10 + 0) if N did not exist before.

0xdeadbeef
Posts: 3
Joined: Tue Mar 27, 2018 10:38 pm

Re: INPUT command lifts stack

Post by 0xdeadbeef » Wed Apr 18, 2018 7:06 pm

Errm, embarrassing to say but you're right about the 42S. Tried it again a few times and it returns 17 indeed (if N contained 7 before).
Must have messed something up the first time I tried.

That being said, I also tried it again on a physical HP 35S and the official emulator ("Virtual Calculator") and in this case, the result really is 15 (when N was 7).

User avatar
pica
Posts: 20
Joined: Fri Mar 30, 2018 9:36 am
Location: eSwatini

Re: INPUT command lifts stack

Post by pica » Wed Apr 18, 2018 7:33 pm

The problem arises when you change the number in N.
I first noticed this when I wrote a routine and INPUT N just before I needed it, rather than at the beginning. The result was that the first run of the routine gave a nonsense answer, but the second time around, when N already had the right value and I didn't change it (i.e. no stack lift), it ran fine. When I single stepped I found that on the next step the number that I input multiplied with the previous, no longer relevant value of N instead of the number that was on the stack. It means that the INPUT command behaves differently if you do or do not change the value of a variable, and that is not OK. It makes INPUT pretty much unusable unless it is only to input and save at the beginning of a routine. And yes, the HP35s does not do this. I do not have a 42s.

0xdeadbeef
Posts: 3
Joined: Tue Mar 27, 2018 10:38 pm

Re: INPUT command lifts stack

Post by 0xdeadbeef » Wed Apr 18, 2018 8:01 pm

Somehow my last post didn't appear (yet). So again: sorry, I was wrong about the HP 42S. Tried it again, my revision A also return 17 if N was 7. Don't know what I did there to get 15. My bad.
But indeed the HP 35S returns 15 if N was 7 (or whatever).

Thomas Okken
Posts: 486
Joined: Tue May 02, 2017 3:48 pm
Location: New Jersey, USA
Contact:

Re: INPUT command lifts stack

Post by Thomas Okken » Wed Apr 18, 2018 9:17 pm

OK, so there is no bug here. You just don't like how the HP-42S/Free42/DM42 Version of INPUT works.

Thomas Okken
Posts: 486
Joined: Tue May 02, 2017 3:48 pm
Location: New Jersey, USA
Contact:

Re: INPUT command lifts stack

Post by Thomas Okken » Wed Apr 18, 2018 10:22 pm

Hmm, when I posted my previous message, 0xdeadbeef's last message wasn't there, despite it now showing up with a time stamp that's 1 hour 16 minutes earlier than mine. If I had seen that message, I wouldn't have posted mine, but with a 76-minute gap between them, this was not a garden-variety case of ninjaing. And this is the second time this has happened to me within a few days, and apparently 0xdeadbeef noticed something like this, too.

Michael or grsbanks, you might want to take a look at your server logs, it seems like there's something screwy going on...

Post Reply