Algorithm for entering numbers?

08112019, 04:36 PM
Post: #1




Algorithm for entering numbers?
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 

08112019, 04:57 PM
Post: #2




RE: Algorithm for entering numbers?
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 HP42S, it's a bit more complicated, and the RPL machines are a different story altogether, but on almost all of the fourlevel HP calculators, this is all there is to it. 

08112019, 05:06 PM
(This post was last modified: 08112019 05:06 PM by Ángel Martin.)
Post: #3




RE: Algorithm for entering numbers?
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 

08112019, 05:37 PM
Post: #4




RE: Algorithm for entering numbers?
Thank you! The SL flag helped a lot and now my code is working.
 Bob 

08112019, 06:35 PM
Post: #5




RE: Algorithm for entering numbers?
(08112019 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 HP48GX 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 

08112019, 07:03 PM
(This post was last modified: 08112019 07:04 PM by rprosperi.)
Post: #6




RE: Algorithm for entering numbers?
(08112019 06:35 PM)Csaba Tizedes Wrote: ...I read the manual from the first letter to the last. 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... Bob Prosperi 

08112019, 07:17 PM
Post: #7




RE: Algorithm for entering numbers?
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 

08112019, 07:38 PM
Post: #8




RE: Algorithm for entering numbers?
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 HP97 manual, and in addition to those four stackliftdisabling 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 HP97 has a LASTx bug? I should check my 67 now. Learn something new every day. 

08122019, 05:36 AM
(This post was last modified: 08122019 05:39 AM by Ángel Martin.)
Post: #9




RE: Algorithm for entering numbers?
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? 

08122019, 08:08 AM
Post: #10




RE: Algorithm for entering numbers?
(08122019 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. There are only 10 types of people in this world. Those who understand binary and those who don't. 

08122019, 08:34 AM
(This post was last modified: 08122019 08:40 AM by Ángel Martin.)
Post: #11




RE: Algorithm for entering numbers?
(08122019 08:08 AM)grsbanks Wrote:(08122019 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. 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 onthefly). But I still don't like that, I guess I value more the consistency with the twostep 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 HP42S, is it correct? And on the DM42 by extension it should also behave the same way... does it? (08122019 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... 

08122019, 09:09 AM
(This post was last modified: 08122019 10:20 AM by grsbanks.)
Post: #12




RE: Algorithm for entering numbers?
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 HP42S. There are only 10 types of people in this world. Those who understand binary and those who don't. 

08122019, 10:26 AM
Post: #13




RE: Algorithm for entering numbers?
(08122019 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 HP42S, is it correct? 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 HP42S, 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. 

08122019, 10:44 AM
(This post was last modified: 08122019 10:45 AM by grsbanks.)
Post: #14




RE: Algorithm for entering numbers?
(08122019 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. (08122019 08:34 AM)Ángel Martin Wrote: I guess I value more the consistency with the twostep 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. There are only 10 types of people in this world. Those who understand binary and those who don't. 

08122019, 10:54 AM
Post: #15




RE: Algorithm for entering numbers?
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 

08122019, 12:44 PM
Post: #16




RE: Algorithm for entering numbers?
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... 

08172019, 07:35 PM
Post: #17




RE: Algorithm for entering numbers?
(08112019 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! I strongly agree. Also what a work in the link you used (as well as the link given by rprosperi) Wikis are great, Contribute :) 

« Next Oldest  Next Newest »

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