Algorithm for entering numbers?

[rea5245]

Hi,

I'm implementing an RPN calculator and I'm confused about the algorithm for entering numbers. It's weird, since I've been using HPs for decades, and yet I realize now I'm not sure how they work!

When you type in a number, it goes into X. When you press Enter, it gets copied into Y. When you start entering a new number, it overwrites what's in X.

But if you type in a number, do not hit Enter, but you hit 1/x, the X register holds the result. Then, when you start entering a new number, the result of 1/x gets pushed into Y before you overwrite X.

So sometimes when you start typing a number, it simply overwrites; other times, it pushes then overwrites.

How does an HP calc decide whether to push X or not?

Thank you,
Bob

[Thomas Okken]

As a general rule, when you start entering a number, or recall a number from a register, the stack lifts, i.e. X is pushed into Y, Y is pushed into Z, Z is pushed into T, and T is lost.

There are only a small number of exceptions to this rule. The stack is not pushed, and X is overwritten instead, after ENTER, CLX, Σ+, and Σ-. These operations are said to disable stack lift; all other functions enable it.

On the HP-42S, it's a bit more complicated, and the RPL machines are a different story altogether, but on almost all of the four-level HP calculators, this is all there is to it.

[Ángel Martin]

We take all this for granted, I had the same thoughts when putting together the 41Z while working on the Complex Stack rules.

The key is the stack lift CPU flag (SL for short). If the flag is enabled, the content of X is pushed into Y, and if 'it's disabled it's not.

The first digit of the number you type pushes X into Y and disables the SL flag. When you're done typing digits and press ENTER, that enables the SL again.

the SL is enabled most of the time, like right after the 1/X function and pretty every other function for that matter - that ensures the proper dynamics of the RPN stack.

Some exceptions: CLX disables the SL, as usually it's done as part of the digit entry sequence.

Cheers,
ÁM

[rea5245]

Thank you! The SL flag helped a lot and now my code is working.

- Bob

[Csaba Tizedes]

(08-11-2019 04:36 PM)rea5245 Wrote:  It's weird, since I've been using HPs for decades, and yet I realize now I'm not sure how they work!

Decades...

When I bought one of these marvels, I read the manual from the first letter to the last.
It is impossible, you never heard about Stack Lift Enabled/Disabled rules.
BTW: I have a good friend, a big HP-48GX expert, he can't to operate my 32SII.

Read the manual - the HP manuals are really the best written ones, maybe you will find something other stuff you never realized during that decades...

Csaba

[rprosperi]

(08-11-2019 06:35 PM)Csaba Tizedes Wrote:  ...I read the manual from the first letter to the last.
It is impossible, you never heard about Stack Lift Enabled/Disabled rules.

It appears that you missed one or two pages, see here:

https://archived.hpcalc.org/greendyk/hp4...l/247.html

Most likely, stuck pages. It can, and does, happen and always with the important ones...

[rea5245]

I looked in the HP 35 and HP 97 manuals and did not see it. Which doesn't mean it wasn't there, of course. I just want y'all to know I looked for it before posting here.

-Bob

[Thomas Okken]

I don't think it's mandatory to exhaust every possible way of finding an answer yourself before asking on a forum. If anyone doesn't want to answer, they don't have to!

Anyway, this little thread prompted me to take a peek at the HP-97 manual, and in addition to those four stack-lift-disabling functions I mentioned earlier, tucked away in an appendix just like in the 41C manual, I noticed an intriguing footnote: https://archived.hpcalc.org/greendyk/hp97/294.html

So the HP-97 has a LASTx bug? I should check my 67 now. Learn something new every day.

[Ángel Martin]

This reminds me a philosophical question related to saving x in LastX:

what should be saved in LastX with RC+, RC-, RC/, RC*
x or the register value invoked?

I'd say the register's value but I'm aware of implementations that do the opposite (which will remain unnamed ;-)
For example, RC+ nn is equivalent to { RCL nn, followed by + } and logically the Rnn value becomes the new "x" before the addition.

Your take?

[grsbanks]

(08-12-2019 05:36 AM)Ángel Martin Wrote:  For example, RC+ nn is equivalent to { RCL nn, followed by + } and logically the Rnn value becomes the new "x" before the addition.

My take is that the value in Rnn is still preserved in Rnn after the operation while the value in X that it is added to is lost. The stack can therefore be reconstructed in its original form with [CLX] [LASTX] if the initial value of X is what is saved in LASTx.

Of course, the same could be achieved by following up with RC- nn but you might lose some precision depending on the difference between Rnn's and X's exponents.

[Ángel Martin]

(08-12-2019 08:08 AM)grsbanks Wrote:  

(08-12-2019 05:36 AM)Ángel Martin Wrote:  For example, RC+ nn is equivalent to { RCL nn, followed by + } and logically the Rnn value becomes the new "x" before the addition.

My take is that the value in Rnn is still preserved in Rnn after the operation while the value in X that it is added to is lost. The stack can therefore be reconstructed in its original form with [CLX] [LASTX] if the initial value of X is what is saved in LASTx.

Interesting view, somehow it reinforces the notion that "LastX" is whatever was last in x before executing the function, regardless of wthat might be (even bringing other values from memory on-the-fly). But I still don't like that, I guess I value more the consistency with the two-step approach ( RC+ = RCL , + ) just to be on the safe side.

BTW I did a check on Free42 and it appears to follow your option, so you're in good company as supposedly that's also how HP did it on the original HP-42S, is it correct?
And on the DM-42 by extension it should also behave the same way... does it?

(08-12-2019 08:08 AM)grsbanks Wrote:  Of course, the same could be achieved by following up with RC- nn but you might lose some precision depending on the difference between Rnn's and X's exponents.

True as well, something more to consider...

[grsbanks]

Also, if you do RC* nn and Rnn is zero, then you can't reconstruct the stack again with RC/ nn. Your original X is lost forever.

Edit: as expected, the DM42 does store the old value of ST X in ST L. I'll have to wait until I get home later to try on my HP-42S.

[Thomas Okken]

(08-12-2019 08:34 AM)Ángel Martin Wrote:  BTW I did a check on Free42 and it appears to follow your option, so you're in good company as supposedly that's also how HP did it on the original HP-42S, is it correct?
And on the DM-42 by extension it should also behave the same way... does it?

RCL arithmetic behaves like unary functions: no stack lift or drop, and the old contents of X are preserved in LASTX. Even if Free42 wasn't written to be compatible with the HP-42S, I'd still have implemented those functions that way, because it's logically consistent *and* more useful than the alternative, as grsbanks pointed out. If you want the semantics of RCL nn +, just do RCL nn +, not RCL+ nn.

[grsbanks]

(08-12-2019 08:34 AM)Ángel Martin Wrote:  Interesting view, somehow it reinforces the notion that "LastX" is whatever was last in x before executing the function, regardless of wthat might be

Exactly, because the value in X is the one that's otherwise going to get clobbered by the operation, so this is the only way of bringing it back from the dead.

(08-12-2019 08:34 AM)Ángel Martin Wrote:  I guess I value more the consistency with the two-step approach ( RC+ = RCL , + ) just to be on the safe side.

I see where you're coming from, but the whole point of register arithmetic operations is that they mean you don't recall anything into the stack, thus preserving T as a positive side effect. In this respect, "RCL[op] nn" and "RCL nn [op]" are not functionally equivalent at all.

[Paul Dale]

I've a feeling that preliminary versions of the 34S firmware didn't touch Last X for recall arithmetic. The way the 42S does it seems natural to me.

Pauli

[Ángel Martin]

ok, you've all convinced me beyond any hesitation ;-D

I guess it's perhaps time to change the RCL Arithmetic code in the SandMath et al...

[pier4r]

(08-11-2019 07:38 PM)Thomas Okken Wrote:  I don't think it's mandatory to exhaust every possible way of finding an answer yourself before asking on a forum. If anyone doesn't want to answer, they don't have to!

[...]
https://archived.hpcalc.org/greendyk/hp97/294.html

I strongly agree.
Also what a work in the link you used (as well as the link given by rprosperi)

[Albert Chan]

I tripped on RCL stack-lift before.
Say, 99 is stored in memory 00, "RCL 00" should be equivalent to "99 Enter"

But, "RCL 00 Enter" only push only one 99.
The extra Enter does nothing ...

What is the rationale for Enter disable stack-lift ?
Should the alternative be more logical ?

[rprosperi]

(08-19-2019 06:29 PM)Albert Chan Wrote:  What is the rationale for Enter disable stack-lift ?
Should the alternative be more logical ?

To avoid having to press Enter more than once to enter and move a number to the Y register and be ready to accept a new number in the X register.

HP changed this by removing stack-lift disable in the 28C and subsequent RPL machines. RPL approach is definitely more pure and 100% predictable, but RPN approach is more efficient for 'normal' (meaning entering numbers from keyboard) data entry.

There is also a 3rd mode, Entry RPN, but further discussion becomes religious, so I'll just leave it like that.

[ijabbott]

(08-19-2019 06:29 PM)Albert Chan Wrote:  I tripped on RCL stack-lift before.
Say, 99 is stored in memory 00, "RCL 00" should be equivalent to "99 Enter"

But, "RCL 00 Enter" only push only one 99.
The extra Enter does nothing ...

What is the rationale for Enter disable stack-lift ?
Should the alternative be more logical ?

The alternative requires an extra register to hold the number being typed. It's hardly a concern these days, but it was back in the early 1970s.