Bug in the HP-41 with R/S and stack lift
10-31-2020, 05:10 AM (This post was last modified: 10-31-2020 05:11 AM by hth.)
Post: #1
 hth Senior Member Posts: 394 Joined: Mar 2014
Bug in the HP-41 with R/S and stack lift
I found another bug in the HP-41. It enables stack lift when starting a program which means that the following program:

Code:
 8 ENTER 9

If you interrupt the program (press the R/S key) at the 9 line, you have just executed ENTER and have the stack lift disabled. If you now press R/S again to continue running, you will end up with:
Code:
 8 8 9
on the stack.
10-31-2020, 05:14 AM (This post was last modified: 10-31-2020 05:16 AM by hth.)
Post: #2
 hth Senior Member Posts: 394 Joined: Mar 2014
RE: Bug in the HP-41 with R/S and stack lift
This also happens with the CLD function.

Code:
 8 ENTER CLD 9

Also results in:

Code:
 8 8 9

on the stack.

I am not sure if it is a bug with CLD, it may be documented behavior.
10-31-2020, 06:24 AM
Post: #3
 Didier Lachieze Senior Member Posts: 1,233 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
I don't think it's a bug, according to the HP-41C Owner's Handbook and Programming Guide, Appendix C:

Quote:All operations on the HP-41C other than those listed below (under Disabling Operations and Neutral Operations) enable the stack lift.

R/S and CLD are not listed in the Disabling or Neutral Operations, so they are working as per the manual.
10-31-2020, 07:36 AM
Post: #4
 hth Senior Member Posts: 394 Joined: Mar 2014
RE: Bug in the HP-41 with R/S and stack lift
So you think pressing R/S to stop a program, immediately followed by R/S again to resume, and this may cause the program to have different behavior than if you had let it run, is not a bug?
10-31-2020, 09:53 AM
Post: #5
 toml_12953 Senior Member Posts: 1,508 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
(10-31-2020 07:36 AM)hth Wrote:  So you think pressing R/S to stop a program, immediately followed by R/S again to resume, and this may cause the program to have different behavior than if you had let it run, is not a bug?

Since it works the way the manual says it does, it is not a bug. It's not a good thing to have happen but it's not a bug. There's a difference.

Tom L
I don't care for whom you voted. If you put ice in your beer, you're crazy.
10-31-2020, 11:47 AM
Post: #6
 Didier Lachieze Senior Member Posts: 1,233 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
That's an interesting corner case, because in general I think that you would not want R/S to be neutral with regard to stack lift. When starting a program sequence with R/S I expect stack lift to be enabled, otherwise the following sequence would provide a different result if the user enters 0 or just press CLx before pressing R/S:

Code:
STOP 2 +
in the first case the result would be 0+2, in the second case it would be Y+2.

I'm wondering how this is managed on other HP RPN calculators, either before or after the 41C.
10-31-2020, 12:19 PM (This post was last modified: 10-31-2020 12:21 PM by Sylvain Cote.)
Post: #7
 Sylvain Cote Senior Member Posts: 1,443 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
Since it is documented, I agree it is not a bug, but IMHO STOP (R/S) should have been stack lift neutral.
10-31-2020, 12:56 PM (This post was last modified: 10-31-2020 01:00 PM by J-F Garnier.)
Post: #8
 J-F Garnier Senior Member Posts: 464 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
(10-31-2020 11:47 AM)Didier Lachieze Wrote:  That's an interesting corner case, because in general I think that you would not want R/S to be neutral with regard to stack lift. When starting a program sequence with R/S I expect stack lift to be enabled, otherwise the following sequence would provide a different result if the user enters 0 or just press CLx before pressing R/S:
Code:
STOP 2 +
in the first case the result would be 0+2, in the second case it would be Y+2.

Good point, actually PROMPT is very often used to enter values followed by R/S.

On the other hand, sequences like "8 ENTER 9" were almost never used by 80's HP-41 users, who just used "8 9" (doesn't save a byte but is marginally faster) so the R/S stack lift enable effect is rare (although yes it can happen so it's good to know it).

J-F
10-31-2020, 01:22 PM
Post: #9
 rprosperi Senior Member Posts: 4,455 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
It's an interesting observation for sure, though I'm curious how you are able to so precisely press [R/S] upon the 9 step (in the original example). I assume the amazingly unlikely ability to do this deliberately, or maybe the more likely chance that this never occurred on a susceptible stack configuration during testing led to it being simply something HP did not encounter.

This behavior being consistent with the manual is IMHO probably a coincidence and while therefor not technically a 'bug' in the classic sense, I would agree that it was not what HP intended.

How on earth did you find this and how many attempts did it take to characterize it?

--Bob Prosperi
10-31-2020, 06:03 PM (This post was last modified: 10-31-2020 06:05 PM by hth.)
Post: #10
 hth Senior Member Posts: 394 Joined: Mar 2014
RE: Bug in the HP-41 with R/S and stack lift
I think that normally you want stack lift to be enabled when pressing R/S, as it allows two identical numbers to be entered on the stack like:

Code:
 42 ENTER RUN

You expect this to be two numbers when starting the program and it should be allowed for the program to push a number the first thing it does without disrupting your two entered values. That is consistent with any built in function like PLUS.

The manual is not the law, it merely documents the behavior of the implementation.

What is a bug (in my view) is that it does something wrong, unintentional by design or possibly something weird you would never expect.

I still think it is a bug, but it is by design and not really fixable as it would break other desired behavor. The cure would hurt more than the problem.

It is true that you seldom have stack lift disabled in a running program. Only CLX and ENTER do it and they are not so common in programs unless you are a newbie.

How I found it? Well, I did not manage to trip it by accident. I was debugging a replacement for the R/S key (for the Boost module) and single stepped the whole thing in VS Code and stepped into the NWGOOS (new goose, LoL) and noticed that it ends with a jump to NFRPU (normal function return, set push flag) like most functions. It just clicked in my head, what happens if a program looks like this and I stop and restart it at the "wrong point"? It took about 10 tries using a trivial (made for the purpose) program to trip the unexpected behavior.
10-31-2020, 11:50 PM
Post: #11
 rprosperi Senior Member Posts: 4,455 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
I fully agree with you! In the manual or not, actually a bug or not, either way it simply isn't 'right' but as you say it had to stay that way, if they even noticed it.

Thanks for explaining how you found it. Although a sensible explanation I guess the odds of your reply being 'I just randomly found it by mistake' seemed a lot higher than 'I found it debugging a replacement for the [R/S] key', LOL.

--Bob Prosperi
11-01-2020, 09:17 AM
Post: #12
 Paul Dale Senior Member Posts: 1,670 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
Didn't the HP-25 not enable stack lift when R/S was used to start a program? This difference has confused me in the past.

Pauli
11-01-2020, 09:33 AM
Post: #13
 Didier Lachieze Senior Member Posts: 1,233 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
On the HP-25 R/S doesn't terminate digit entry which can also be confusing as discussed here.
11-01-2020, 09:58 AM
Post: #14
 Paul Dale Senior Member Posts: 1,670 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
Thanks Didier, that's the one.
11-01-2020, 03:35 PM
Post: #15
 ijabbott Senior Member Posts: 921 Joined: Jul 2015
RE: Bug in the HP-41 with R/S and stack lift
Can this be reproduced on HP-42S?

With a cleared stack, for:
Code:
LBL "AAA" 8 ENTER 9

I tried single-stepping past the 'ENTER' and then pressing 'R/S' and ended up with the stack contents:
Code:
0  0 8 9

— Ian Abbott
11-01-2020, 05:08 PM
Post: #16
 Thomas Okken Senior Member Posts: 1,120 Joined: Feb 2014
RE: Bug in the HP-41 with R/S and stack lift
(11-01-2020 03:35 PM)ijabbott Wrote:  Can this be reproduced on HP-42S?

On the HP-42S, R/S does not enable stack lift, neither when used to interrupt a running program nor when used to start or resume program execution.

The STOP command, in a program, does enable stack lift, though.
11-02-2020, 01:15 PM
Post: #17
 vassilisprevelakis Member Posts: 56 Joined: Mar 2014
RE: Bug in the HP-41 with R/S and stack lift
(10-31-2020 05:10 AM)hth Wrote:  I found another bug in the HP-41. It enables stack lift when starting a program which means that the following program:

Code:
 8 ENTER 9

Actually you do not need the ENTER since the HP41 numbers are fully merged.
You'd need the ENTER in previous calculators (e.g. HP-67) where numbers were
not merged, so you needed a way to separate them.

So, if you take out the ENTER, the program will work correctly even if interrupted.

**vp

PS OK I know this does not address your point, but I thought I'd point this out anyway :-)
11-02-2020, 01:15 PM
Post: #18
 Ángel Martin Senior Member Posts: 1,183 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
Bug or not it's certainly peculiar - to the point of not "feeling" right... but it isn't the only case out there. For instance I keep assuming that ST+ puts the X value in LastX, which it does not.... counter-intuitive for me.
11-02-2020, 01:29 PM
Post: #19
 vassilisprevelakis Member Posts: 56 Joined: Mar 2014
RE: Bug in the HP-41 with R/S and stack lift
(11-02-2020 01:15 PM)Ángel Martin Wrote:  Bug or not it's certainly peculiar - to the point of not "feeling" right... but it isn't the only case out there. For instance I keep assuming that ST+ puts the X value in LastX, which it does not.... counter-intuitive for me.

You are sooo right, even if I like it just fine that ST+ does not mess with LASTx
(after all how would it deal with ST+ L :-)

With RPN, HP tried to make things "intuitive" rather than consistent, but clearly not everybody agrees on what is intuitive so RPN is better described as ad hoc, and you have to expect surprises.

I guess the rule is that if one wants consistency, RPL is the way to go.

**vp

PS I like surprises.
11-02-2020, 05:33 PM
Post: #20
 Ángel Martin Senior Member Posts: 1,183 Joined: Dec 2013
RE: Bug in the HP-41 with R/S and stack lift
(11-02-2020 01:29 PM)vassilisprevelakis Wrote:  I guess the rule is that if one wants consistency, RPL is the way to go.

OMG, pls. gimme many many more inconsistencies !! ;-)
 « Next Oldest | Next Newest »

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