HP 12C Platinum CHS bug?


I know this has come up before but what I read did not have much info so here goes again...

I was searching for some other info today and came across mention of a weird stack/CHS bug in the 12C Platinum. Specifically the following:

10 ENTER CHS 2 + returns 12 and not -8.

Ok, I guess I can live with that. However, the following was also noted in a post I came across:

10 ENTER CHS 2 +
5 ENTER 5 + CHS 2 +

Give different answers. This strikes me as being totally inconsistent. So here is my question: Is this considered a bug and does this bug (idiosyncrasy if you prefer) exist in all the 12C Platinum versions? It certainly exists on mine (CNA 01705175).

BTW, I tried this on all the calculators I have out at the moment and the only other ones to exhibit this behavior are the HP65, HP45, and HP25 although it was argued that this is documented in the HP25 manual and therefore is NOT a bug. I don't have any of the manuals available right now so I can't verify one way or the other. With the listed machines the behavior is identical with respect to both examples given above. The HP35 (NOT S) does something completely different returning 8 for both examples above (at least it is consistent).




These are not bugs, but simply the way the calculator executes a stack lift. On the HP-35, Once you press ENTER, any further operations apply to the next value being entered into the X register, so the 10 in your example has been lifted into the Y register, and the negative sign is applied to the 2 that is keyed in after it. So in this case you have +10 -2 = +8. On the HP-45, when you ENTER the 10, a +10 is lifted into the Y register, then the CHS is cancelled when you key in the 2, so you end up with +10 in the Y register and +2 in the X register, and the result is +10 +2 = +12. Basically, the proper and consistent way to use any RPN calc is to key in all parts of a number (mantissa, sign, exponent, sign) prior to entering it into the stack to avoid this type of problem. The proper way to calculate -10 + 2 = -8 is to key in 10 CHS ENTER 2 +

Edited: 11 Aug 2011, 5:49 p.m.


Standard 12 gives -8 when 10 ENTER CHS 2 + is keyed in, so 12C+ definitely gives a different result.

HP-41CX also gives -8, so it is likely that the emulation in 12C+ has a bug somewhere (it is supposed to give the same result as the emulated 12C).

Even Nonpareil emulation of 12C gives -8 (and it is likely that 12C+ is based on nonpareil emulation).


Edited: 11 Aug 2011, 6:14 p.m.


Not a bug, just improper user entry. Try 10 CHS ENTER 2 +, and you'll get the correct answer -8 on every machine, every time.


Sure, that works, and that is how I would usually do it. But the results are inconsistent among calculators so if nothing else it is an idiosyncrasy.


Vladan, M. Joury is talking about the 12C Platinum which is a complete reimplementation of the 12C with enhancements. The software writers introduced a few bugs in the process of reinventing the wheel. The 12C+ emulates the 12C hardware and runs the original ROM so the results on a 12C+ should match those of the 12C.


It does.



The sequence 10 ENTER CHS 2 + on my 15C puts 10 in X, duplicates the value (stack lift disabled) then executes a monadic operation on X, replacing X by -X. This enables stack lift again so that the 2 pushes 10 into Z, -10 into Y and 2 in X. + adds -10 to 2 and replaces X by the result, dropping both input values so that 10 is now in Y which can be easily checked with Rv.


Yup. 15C was one of the machines I tried. As was the WP34S <g>. Both gave -8 as a result for both problems. So do the following machines:


Edited: 11 Aug 2011, 8:40 p.m.


Yes, it is a bug. The CHS is not listed as a neutral operation (15C manual Appendix B)

The CHS is neutral during digit entry.

"After digit entry termination, CHS and EEX are lift-enabeling". The ENTER terminates the first number



This answer is the most sensible to me.

In the 15C and others, the sequence "10 ENTER CHS" appears to intentionally enter 2 numbers (+10 into Z and -10 into Y), so that anything following will replace the display. Most of us performing this sequence probably don't think about the Z value and intend only to work with the X and Y registers, making -8 the expected result.

But if you think about what Michael Estrada said, our habit of ignoring the Z value is equivalent to an incorrect input method for RPN, where if we didn't want +10 in the Z register, we really should be typing "10 CHS ENTER" and not "10 ENTER CHS".

Just my C$0.02

Edited: 12 Aug 2011, 10:47 a.m.


Unless I am misunderstanding what you are saying, I don't think that is right.

'Z' never gets involved. Assuming a clear stack to begin with (all zeroes) on the 15C:

10 CHS ENTER -->  Y: -10;  X: -10
10 ENTER CHS --> Y: 10; X: -10

Nothing ends up in 'Z'.

You get the EXACT same results on the 12CP, *BUT* on that machine CHS after ENTER appears to DISABLE stack lift (see my additional comments at the end). So any digits entered after that overwrite the -10 in the X register.

Per Tommy (from the HP-15C manual:

"After digit entry termination, CHS and EEX are lift-enabeling". The ENTER terminates the first number

This is identical to the operation of *MOST* hp calculators that I have tested including the original HP-12C and the HP-12C+.

I agree with Michael that this entry method is suspect and probably not the best way to do things but most other HP's handle it as I would expect. Also, see Gerson's reply in this same thread for an example where the behavior of the 12CP might get you in trouble.

One final point (made earlier) is that the result is not consistent. CHS after ENTER behaves differently than, say, after '+'. Try:

5 ENTER 5 + CHS 2 +

This gives you a result of -8 on every machine I have tested *OTHER THAN* the HP-35 which gives you 8. In the above example the CHS operation either enables stack lift or is neutral ('+' enabled it), either way the result is different.

I just realized that I think I know what is going on:

On most HP's CHS is neutral *EXCEPT* after digit entry (as suggested by the HP-15C manual). On the HP-12CP it is *ALWAYS* neutral and since ENTER disables stack lift CHS (neutral) leaves stack lift disabled and the next digit overwrites 'X'. That also explains the behavior with 5 ENTER 5 + where '+' enables stack lift and CHS (neutral) does not effect it so -10 is 'lifted' into 'Y when the next digit is entered. I will have to play around with this some and see if my assumption is consistent.




No, you didn't misunderstand. I made a mistake in trying to be too brief with my post. By leaving out the "2" following "10 ENTER CHS", of course nothing ends up in Z, so I should have left the original sequence intact. Reconsider my post with the extra digit entry at the end.

I was just trying to emphasize the important difference when the CHS came before ENTER rather than after. The benefit of the 15C method of entry with the additional stack lift is that it keeps the concept of CHS being postfix. When it's applied to the "2" as a prefix notation, the result is unexpected for most of us. But if we kept to the rule as suggested by Mike Estrada, the problem wouldn't arise.

Hopefully I've cleared up the mess I started.


Makes sense to me. But to address one thing you said:

When it's applied to the "2" as a prefix notation, the result is unexpected for most of us.

I think that this is only happening on the HP-35. On the HP-12CP and the other machines with the same behavior the CHS is *NOT* applied to the '2'. It simply is completely neutral as far as enabling stack lift and the '2' overwrites the -10 in the 'X' register.

In other words the 'Z' register is NOT effected on the 12CP. What you end up with after 10 ENTER CHS 2 (before the final '+'):

On the 15C:  Z:   10;  Y:  -10;  X:    2
On the 12CP: Z: 0; Y: 10; X: 2
On the 35: Z: 0; Y: 10; X: -2

So we have here 3 different approaches to handling this keystroke sequence. 1 and 3 at least give consistent results when considering the other example given earlier (5 ENTER 5 + CHS 2 +). I believe that, per the HP-15C manual, CHS should ENABLE stack lift after digit entry termination.

As it happens I generally use the approach offered by Michael, but I am sure that, as suggested by Gerson in his posting, I have on occasion forgotten the CHS until after I pressed enter. On the 12CP this would return an unexpected result.



Edited: 12 Aug 2011, 5:58 p.m. after one or more responses were posted


Marvan, you should replace "T:" by "Z:" in your post. Otherwise this makes it perfectly clear.

Edit: done. :-)

Edited: 13 Aug 2011, 4:39 a.m. after one or more responses were posted


Oops :-). I will fix it. Thanks!


I would agree that the HP35 action does not qualify as a bug since, at the very least, the results for the two problems are consistent. On the HP35 the monadic +/- appears to push the leading sign onto the stack and any digits entered thereafter are negative. But the inconsistency with the results on the HP-12C Platinum (and others mentioned) makes it appear like a bug to me.

Furthermore, with the 12CP the monadic negation operator simply disapears. It does not effect 10 and it does not effect 2. The reason, of course, is that CHS appears to disable stack lift on the 12CP and therefore -10 is overwritten by 2. So what you end up with is 10 in the Y register and 2 in the X register. This is not how *most* HP calculators appear to work.

It would appear that CHS after ENTER on the 12CP (and some others) operates differently than at other times (with 5 ENTER 5 + CHS 2 + the CHS operator does NOT disable stack lift or else the final result, assuming an initial stack filled with zeroes, would be 2).



Edited: 11 Aug 2011, 8:56 p.m.


On the 12CP, CHS simply leaves stack lift alone which is a bug because it acts on the number in X (changing the sign) without preserving this changed value as an "automatic intermediate result". If you read the explanation of RPN in the 12C manual you know what I mean.


Yes, as I mentioned elsewhere, I suddenly realized that on the 12CP the CHS is *ALWAYS* neutral as far as enabling or disabling stack lift. Per the HP-15C manual (quoted by Tommy):

"After digit entry termination, CHS and EEX are lift-enabeling".

So, one could argue that other machines that have this behavior are "as designed" but for the 12CP which is supposed to be a more advanced version of the 12C I would say it is a bug. It would appear that at some point (at least two) the implementation of RPN changed. It changed after the HP-35 (all other classics have the second implementation?) and, apparently, again after the Woodstocks. The Implementation of the 12CP is a throwback to that in the HP-45, HP-65, and Woodstocks. Was the HP-67 the first with the third implementation? BTW, the HP-55 can be added to the machines that do it the second way.




We had some stack lift problems with the 34S firmware recently. The whole stack lift business is a bit convoluted at best. On the 34S we could easily change the way ENTER works: Instead of duplicating X and lifting the stack it could simply terminate digit entry. In such a scenario, stack lift is always enabled. With this approach (borrowed from the RPL machines) 2 ENTER x will no longer produce the result 4 as on a classic RPN calculator. But it would ease the implementation significantly and there will be no ambiguities left.


Marcus, I hear what you are saying. I have implemented an RPN simulator for the HP-39gs and the hardest part to get right was the stack lift. It seems so easy and yet it is not really trivial.




With this approach (borrowed from the RPL machines) 2 ENTER x will no longer produce the result 4 as on a classic RPN calculator

... and thus be duplicating the behavior of the base 20b/30b machine.

I don't like this option at all and is one of the reasons why I don't use the 20b/30b.

Edited: 12 Aug 2011, 10:56 p.m.


Is this considered a bug ...

I would say so: it's not the same as the original 12C (which gives -8) so it's certainly a bug in the sense that keystroke programs published for one machine won't necessarily work on a Platinum.
...and does this bug (idiosyncrasy if you prefer) exist in all the 12C Platinum versions? It certainly exists on mine (CNA 01705175).

It's in my Anniversary Edition Platinum.


If this is not a bug it is a very cumbersome feature, to say the least. In article #654, last edited on 12/30/2006, I wrote:


3) Pay attention to what appears to be a bug in the HP-12C Platinum: negating a number just entered by pressing
the CHS (change sign) key does not work the way it used to on the classic HP-12C. For instance:

Keystrokes Display

45 ENTER 45.00000000
CHS -45.00000000 The number displayed by the calculator is negative,
5 5.
+ 50.00000000 yet it has been interpreted as a positive number.

15 ENTER 15.00000000 we've just entered 15,
CHS -15.00000000 but then we rememember we want to compute sin(-15) and press CHS
R/S 0.258819045 then R/S. Wrong result, the calculator shows sin(15) instead!

So, either we enter the correct number the first time or we remember to press ENTER after pressing CHS:

15 CHS R/S -0.258819045 sine(-15)
15 ENTER 15.00000000
CHS ENTER -15.00000000
R/S -0.258819045 sine(-15), as expected.

Possibly Related Threads…
Thread Author Replies Views Last Post
  HP Prime graphing bug BruceH 1 1,498 11-19-2013, 08:14 AM
Last Post: Joe Horn
  HP Prime - another cosmetic bug BruceH 3 1,731 11-12-2013, 02:18 PM
Last Post: Ken Shaw
  HP 12C Platinum Programming v. Gold Face Dean Lewis 10 3,407 11-03-2013, 07:30 PM
Last Post: Kimberly Thompson
  HP-80 CHS Exponent Curiosity Max Stone 4 1,897 10-22-2013, 02:39 PM
Last Post: Max Stone
  HP Prime Bug bluesun08 19 5,436 10-14-2013, 10:48 PM
Last Post: Han
  HP Prime bug in EDITMAT Han 7 2,638 09-27-2013, 10:15 AM
Last Post: Han
  [HP 39Gii] - Bug report Jean-Michel 1 1,637 08-28-2013, 10:53 AM
Last Post: Tim Wessman
  HP12C Platinum PC software activation fails Russell Clinton 0 1,087 07-02-2013, 02:32 PM
Last Post: Russell Clinton
  Is the HP-35S bug free? Matt Agajanian 22 6,409 07-01-2013, 04:03 PM
Last Post: Andrés C. Rodríguez (Argentina)
  HP 12c Platinum Emulator Activation Server Problem Danny Farley 5 1,889 04-09-2013, 09:13 PM
Last Post: Danny Farley

Forum Jump: