SwissMicros Calculator Forum

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.

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.

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.

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

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.

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

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.

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

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

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