CHS and Stack Lift



#2

Here is an interesting observation I have made as I have tried to port a certain program across several RPN calculators.

The routine returns the result, R, and its complement, 1-R in registers X and Y, and you view them both with x<>y as you wish. On occasion, the program may return 0 and I want to compute the complement 1 - R = 1 and end with 0 in the Y register and 1 in the X register.

I have noticed differences across calculators in the treatment of these closing steps if 0 is in the X register:

ENTER
CHS
1
+

On the HP41, HP42, and HP33S, the steps do what I want--they copy the result into Y, change the sign of the X register (null effect when this is 0) and add 1 to the X register, leaving the correct complementary values in the X and Y register. The important point here is that CHS seems to enable stack lift no matter whether the contents of the X-register are zero or not.

However, I have discovered that CHS only seems to enable stack lift on the 11C and 34C when the operand in the X register is not zero. If it is zero, CHS seems to do nothing, and when the 1 is added to the 0 in the X register the register is overwritten and the stack is dropped, so that the Y register holds not zero, as desired, but whatever was in Z register before the addition took place. If the value in the X register is anything but zero, the four steps above have the desired behaviour.

Adding an extra step seems the only way to fix it:

ENTER
ENTER
1
-
CHS

I thought this was a very interesting difference. I don't know if the behaviour in the 11C and 34C is a bug or a feature, but it certainly would be less confusing if it enables stack lift for nonzero operands it would do so for zero too!

Les


#3

Oh, I should note the 15C behaves like the 11C in this regard. Les

#4

Hi, Les --

Interesting find! (Although I'm sure that it's been found before...)

I'd say that the HP-34C/11C/15C/16C response is of an unintended type that H-P eliminated permanently with the Pioneer series. It slipped into the three aforementioned Voyager-series models after the HP-41 debuted, likely due to reuse of ROM code from the HP-34C for the "advanced" Voyagers. The original thinking may have been, "Ignore any command to negate zero", but such processing may sabotage a program that negates a value that might happen to equal zero.

On all HP RPN (not RPL)-based calc's, ENTER disables stack lift. However, there is different behavior in various lines of calculators following CHS with zero in the x-register:

calulator line          CHS on         post-CHS   |    CHS on        post-CHS 
result of zero stack lift | keyed-in zero stack lift
|
HP-34C/11C/15C/16C ignored unchanged | ignored disabled
HP-10C/12C ignored enabled | ignored disabled
HP-41 ignored enabled | ignored disabled
HP-32S/32SII/42S ignored enabled | accepted disabled

"ignored" means that the value is not changed and the negative sign is not displayed.

Regarding "keyed-in zero", one can enter [0][+/-][2][6] on any Pioneer-series model, and see "-026", which is converted to -26.00. On the other ones listed, 26.00 is the result.

Another workaround for the "Spice and Voyager" models that does not disturb the stack is a conditional test:

ENTER
CHS
x=0?
ABS (re-enables stack push)

Here's an example for f(x) = xe1-x on the HP-34C/11C/15C:

	 program     input x    result    |  program   input x    result   
|
LBL A 0 (erroneous) | LBL A 0 0.000
ENTER 1 1.000 | ENTER 1 1.000
CHS 2 0.736 | CHS 2 0.736
1 | x=0?
+ | ABS
e^x | 1
* | +
RTN | e^x
| *
| RTN

"erroneous" means that the function will not be calculated properly, so the user cannot generally expect a correct result.

However, this user function will work properly without the workaround using the HP-15C SOLVE and INTEG, because those built-in functions load the stack with the input argument.

-- KS


Edited: 13 Feb 2007, 1:02 a.m. after one or more responses were posted


#5

Karl:

I like your tables. They are very useful.

Regards,

Bill


#6

Hi, Bill --

Quote:
Karl:

I like your tables. They are very useful.

Regards,

Bill


Thanks for the compliment, but they would have more useful if they had been entirely correct. :-)

Please review my post again to find corrected tables and an example.

Regards,

-- KS

#7

Karl, the workaround is perfect when it is important not ot molest the rest of the stack, but at the cost of two extra steps. In my case, what is happening in X and Y is all that concerns me, so adding the extra ENTER, performing a subtraction instead of addition, and relocating the CHS to the end costs just an extra step and is probably a bit faster. And the 34C and 11C are slow enough as it is!

Many thanks,

Les

#8

Quote:
Interesting find! (Although I'm sure that it's been found before...)

Look here.

Cheers.

Luiz (Brazil)


#9

Hi, Luiz --

Thank you for the recent Archive link. I'd forgotten about that thread, because I don't have an HP-12C Platinum, and don't intend to buy one.

However, the problem listed in the thread is not quite the same one as Les posed. The issue is the post-CHS status of stack lift behavior when zero is in the x-register and the the pre-CHS status was "disabled". The 12CP problem was that CHS did rot re-instate stack lift for any value in the x-register.

Trent Mosely seems to have the models whose performance is of interest to me. From last year's thread:

Quote:
Just for the fun of it I tried the program on my red LED models (25C, 31E, and 67) and the bug showed up of all places on the 25C!

tm

Correction. There is NO bug in the 25C on this issue. The Owner's Handbook clearly states on page 111 that a number keyed in following CHS does not affect the stack in other words it overwrites it.

tm



Thanks,

-- KS

#10

I think that the HP33C behaves in the same way (as you might expect) - any one able to try this on an HP10C. I don't have mine handy right now...

It was a later model and past experience indicates that it behaves subtly differently (bug fixes?).

Mike T.


#11

Hello,

I think this is my second post here.

I just read this post and tried the examples in my 10C and it behaves as expected, so it enables stack lift as the 41, 42 and 33S. Mine has the S/N 2242A10747.

Regards,

Miguel

#12

In Les' recent finding (or rediscovery):

Quote:
ENTER CHS 1 +

On the HP41, HP42, and HP33S, the steps do what I want--they copy the result into Y, change the sign of the X register (null effect when this is 0) and add 1 to the X register, leaving the correct complementary values in the X and Y register. The important point here is that CHS seems to enable stack lift no matter whether the contents of the X-register are zero or not.

However, I have discovered that CHS only seems to enable stack lift on the 11C and 34C when the operand in the X register is not zero. If it is zero, CHS seems to do nothing, and when the 1 is added to the 0 in the X register the register is overwritten and the stack is dropped, so that the Y register holds not zero, as desired, but whatever was in Z register before the addition took place. If the value in the X register is anything but zero, the four steps above have the desired behaviour.


I've confirmed that this undesired behavior is present on the HP-34C, HP-11C, HP-15C, and HP-16C. It is not present on the HP-10C or HP-12C. The HP-35 responds differently.

I'd like to ask anyone to try Les' test on an HP-67 or HP-33C in particular, on the HP-25/25C and on other Spice-series models for comparison. I suspect that the undesired behavior may have been "inherited" in reused ROM code from the more-advanced predecessors.

Thanks!

-- KS

Edited: 14 Feb 2007, 4:13 a.m.


#13

My 33C (S/N 2241...) and 32E (2116...) behave like the 34C. 27 (1609...) and 21 (1507...) respond differently.


#14

Hi, Walter --

Quote:
My 33C (S/N 2241...) and 32E (2116...) behave like the 34C. 27 (1609...) and 21 (1507...) respond differently.

Thank you for the tests. This may narrow it down. Now, if someone could try it with an HP-67:

9 ENTER ENTER 0 ENTER CHS 1 

is the stack

correct or incorrect?

9 9
0 9
0 0
1 1


-- KS


#15

Hi, Karl,

please note the stack will contain 1 0 9 9 in all 4 models I tested using

9 ENTER ENTER 0 ENTER CHS 1

Using non-zero values, e.g.

9 ENTER ENTER 2 ENTER CHS 1

instead, the stack of the Spices shows 1 -2 2 9 , of the Woodstocks 1 2 9 9 .

Addendum: HP67 (S/N 1803...) shows 1 0 0 9 and 1 -2 2 9, respectively. HP45 performs like the Woodstocks, while HP35 displays -1 0 9 9 and -1 2 9 9.

Regards, Walter

Edited: 15 Feb 2007, 7:11 p.m.


#16

Hi, Walter --

Thank you for conducting the tests on the 1970's models of HP calculators. (My LED-based models include only an HP-35 and an HP-34C.) It certainly seems that, while the pre-1976 models either had some performance issues or had not had their functional specification exactly defined, the HP-67 got it right. Then, a new flaw was introduced in the Spice series, which was then passed on to the "upper level" Voyagers.

Could I ask you for one more test on the HP-67?

9 ENTER ENTER ENTER CLx CHS 1

Is the resulting stack

x   y   z   t        x   y   z   t
1 0 9 9 or 1 9 9 9 ?

Here, the latter would be the desired response, because CLx is intended for clearing the x-register so that a new value can be input. Certainly, the CHS would be superfluous on a value of zero, but is it simply ignored? Was any distinction made between stack lift disabled by ENTER and stack lift disabled by CLx?

Thanks,

-- KS


#17

Perhaps, after all these years?

A very obscure one, at that...if it deserves to be called one at all.

#18

If you want the latter behavior in your example, then you get that with the 11C/15c behavior. The problem is that you then have inconsistent behavior relative to the CHS call. Of course your keystroke sequence in the case is not one that would ever be of value logically. It reminds me a bit of synthetic programming. which some 41 experts relish but which is really totally abstruse and outside normal logical design intent. (OR apparent design intent. Who knows what HP engineers really wanted--perhaps they wanted undocumented synthetic possibility).


#19

Hi, Bill --

Quote:
If you want the latter behavior in your example, then you get that with the 11C/15C behavior. The problem is that you then have inconsistent behavior relative to the CHS call.

More precisely, it would be inconsistent "lift-enabling" behavior after CHS, regarding ENTER and CLx.

Quote:
Of course your keystroke sequence in the case (9 ENTER ENTER ENTER CLx CHS 1) is not one that would ever be of value logically.

Quite right -- "CLx CHS" on a Voyager-series model would exemplify a user error in interactive mode, and would have no practical use in a program. (Recall that CHS on a zero will not display a negative sign on a Voyager-series model; at least one non-zero digit must be present.)

It would be nice if such an error could be ignored, but not at the expense of inconsistent stack-lift-enabling behavior, as exhibited by the Spice- and Voyager-series models for CHS performed upon a result of zero, versus upon a result other than zero.

On the HP-15C, lift-enabling rules for the various commands were also established for complex-valued numbers.

There is a footnote on page 211 of the HP-15C Owner's Handbook:

Quote:

"All digit entry functions are also neutral during digit entry. After digit entry termination, CHS and EEX are lift-enabling; CLx is disabling."

This verbiage, along with my own examination and Walter B's HP-67 results lead me to a clear conclusion:


The failure to re-enable a disabled stack lift upon CHS performed on a result of zero was a bug on at least these identified Spice- and Voyager-series models: HP-32E, HP-33E/C, HP-34C, HP-11C, HP-15C, HP-16C.

This behavior is inconsistent with the logically-correct response first established with the predecessor HP-67, maintained in the HP-41 series, and later restored in the Pioneer series (HP-32S, HP-32SII, HP-42S).

This bug was likely introduced into the Spice series and possibly transferred to the three Voyager-series models by re-use of ROM code. The bug may also be present on the HP-31E, HP-37E and HP-38E/C.

Thanks to all. I'd say that we've got a bit of new material for Craig Finseth's pages regarding these particular modestly-afflicted calculator models.

-- KS


Edited: 18 Feb 2007, 2:46 a.m.

#20

Hi Karl,

HP67 shows 1 0 9 9 in this case. Woodstocks and Spices show 1 9 9 9.

Regards, Walter

Edited: 16 Feb 2007, 6:36 p.m.

#21

Quote:
Using non-zero values, e.g.

9 ENTER ENTER 2 ENTER CHS 1

instead, the stack of the Spices shows 1 -2 2 9


This is also the result for *both* 11c/15c and the Pioneers *and* the 12c.

That the Woodstock comes up with 1 2 2 9 is yet a third variation. I don't understand it though. When you press CHS on a woodstock, don't you see a little minus sign light up in REEEED LEDs? Why did it disappear on pushing 1 onto the stack?


#22

Hi Bill,

Quote:
When you press CHS on a woodstock, don't you see a little minus sign light up in REEEED LEDs?

Yes, I do.
Quote:
Why did it disappear on pushing 1 onto the stack?

In fact, it didn't tell me, but it's gone :)
#23

Intriguing forensics. I have long held the belief, perhaps
shared with many of you (other than Eric) that the Voyagers
were specialisations of a common core of code. Karl's observation
suggests that 10C and 12C shared one set of common code while 11C,
15C and 16C shared a different set.

Thinking of their application, I'd have thought 10, 11 and 15 might
share code and that 12 and 16 would be unique.

Perhaps the code was always written from scratch and what we're
seeing is two schools of design thought about the "correct"
behaviour.

It could also be that there's a "jump if zero" instruction in the
CHS handler that branches to the "wrong" target and that the coder
responsible didn't see the unintended consequence. This would mean
that it's an accident of implementation that wasn't picked up during testing (because no one thought to test the "ridiculous"
boundary case of 0 CHS).

Cameron


#24

Hello, Cameron --

Quote:
I have long held the belief, perhaps shared with many of you (other than Eric) that the Voyagers were specialisations of a common core of code. Karl's observation suggests that 10C and 12C shared one set of common code while 11C, 15C and 16C shared a different set.

That may be overstating it; there is plenty of overlap in built-in functionality between these five models. However, it's noteworthy that the the 10C and 12C had a crude programming paradigm (no LBL, GSB, or insert/delete editing, limited conditional tests and no flags) and lacked the backarrow/backspace key. The 11C, 15C, and 16C had all these features. Although there is still much commonality, the 10C and 12C may have some ROM code lifted from previous models lacking the features, while the 11C, 15C and 16C may have "borrowed" more heavily from the more-sophisticated predecessors. That's my theory, anyway...

Quote:
Perhaps the code was always written from scratch and what we're seeing is two schools of design thought about the "correct" behaviour.

I doubt that very much code was written from scratch unless necessary; too much work and testing went into algorithms and microprocessor instructions not to be re-used.

The way I see it, only one way is correct: CHS on a result of zero (not a zero entered from keyboard) should re-enable stack lift. In a program, a "final value" of zero should not be processed differently than any non-zero final value.

Quote:
It could also be that there's a "jump if zero" instruction in the CHS handler that branches to the "wrong" target and that the coder responsible didn't see the unintended consequence.

This is quite plausible, I think. The origin of this, though, probably lies in an earlier model. "Which one?" is the question. Whence came the flawed gene?

-- KS



#25

I must say, I am curious to hear what Valentin thinks of this.

I just read my 11c manual and compared it to the 32sii manual, and I must say, these two statements are quite clear:

"Digit Entry Termination
"Most operations...terminate digit entry...(The 'CHS', '.', 'EEX',
and '<' operations do not terminate digit entry).

"Stack Lift
...
"Neutral Operations
"...Some operations, like 'CHS' and 'FIX' are neutral; that is,
they do not alter the previous status of stack lift...

"The following operations are neutral on the HP-11C:
"...'CHS'*
"*'CHS' is neutral during digit entry of a number from keys, as in
1, 2, 3, 'CHS' to enter -123; or 123'EEX'6'CHS' to enter
123 X 10^6. Otherwise, 'CHS' enables the stack."

Pay especial attention to this last statement. That's the crux of the matter. It should have enabled the stack to lift. (It is interesting that it doesn't read, "enables the stack LIFT.") It enables the stack to lift with *any other number* left in the X-register that is changed in sign by a 'CHS' command.

That seems like a bug, doesn't it? But I am in shock. It just feels really squirmy to see any bugs in the 15c and 11c!

I wonder if this bug has ever inadvertently bitten me? There are those occasional programs that drive you crazy..that just don't ever seem to debug...

Interestingly, the 32sii manual doesn't go into this special detail regarding whether 'CHS' is applied to digit entry or to a pre-existing X-register number. Rather, 'CHS' is merely lumped into the "stack-lift enabling" category by omission from the neutral table.

Edited: 15 Feb 2007, 12:09 a.m.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP35s Program Four Slings Lift Calculation Jean-Marc Biram (Australia) 2 780 12-16-2013, 07:21 PM
Last Post: Jean-Marc Biram (Australia)
  HP 50g - select characters on the stack, copy/paste Sean Freeman 7 931 11-20-2013, 07:11 AM
Last Post: Sean Freeman
  Prime: Placing more than 1 item on the RPN stack in a single program? John Colvin 4 704 11-19-2013, 08:59 AM
Last Post: Miguel Toro
  emu48 - copy stack doesn't work (as expected) Thomas Radtke 2 706 11-11-2013, 02:19 PM
Last Post: Thomas Radtke
  HP Prime Stack operations from within a program John Colvin 1 492 11-08-2013, 09:45 PM
Last Post: Helge Gabert
  HP-80 CHS Exponent Curiosity Max Stone 4 714 10-22-2013, 02:39 PM
Last Post: Max Stone
  Prime: Anyway to refresh stack? kris223 5 710 10-16-2013, 05:09 PM
Last Post: kris223
  hp prime - sending program results to the stack giancarlo 6 805 10-15-2013, 02:00 AM
Last Post: Giancarlo
  HP Prime - RPN stack access from programs? Mike Mander (Canada) 10 900 09-30-2013, 11:20 AM
Last Post: steindid
  WP-34S: Stack after divide by 0 Marcel Samek 4 475 08-24-2013, 11:57 PM
Last Post: Paul Dale

Forum Jump: