▼
Posts: 756
Threads: 31
Joined: Aug 2010
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).
Cheers,
Marwan
▼
Posts: 1,665
Threads: 142
Joined: Jan 2009
These are not bugs, but simply the way the calculator executes a stack lift. On the HP35, 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 HP45, 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.
▼
Posts: 34
Threads: 0
Joined: Jul 2008
Standard 12 gives 8 when 10 ENTER CHS 2 + is keyed in, so 12C+ definitely gives a different result.
HP41CX 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).
Vladan
Edited: 11 Aug 2011, 6:14 p.m.
▼
Posts: 1,665
Threads: 142
Joined: Jan 2009
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.
▼
Posts: 756
Threads: 31
Joined: Aug 2010
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.
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 756
Threads: 31
Joined: Aug 2010
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 756
Threads: 31
Joined: Aug 2010
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:
HP41
HP42
HP67
HP32Sii
HP33S
HP35S
HP12C
HP12C+
HP34C
HP32E
Edited: 11 Aug 2011, 8:40 p.m.
▼
Posts: 30
Threads: 5
Joined: Jul 2010
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 liftenabeling". The ENTER terminates the first number
/Tommy
▼
Posts: 149
Threads: 7
Joined: Dec 2006
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.
▼
Posts: 756
Threads: 31
Joined: Aug 2010
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 HP15C manual:
Quote:
"After digit entry termination, CHS and EEX are liftenabeling". The ENTER terminates the first number
This is identical to the operation of *MOST* hp calculators that I have tested including the original HP12C and the HP12C+.
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 HP35 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 HP15C manual). On the HP12CP 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.
Cheers,
Marwan
▼
Posts: 149
Threads: 7
Joined: Dec 2006
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.
▼
Posts: 756
Threads: 31
Joined: Aug 2010
Makes sense to me. But to address one thing you said:
Quote:
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 HP35. On the HP12CP 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 HP15C 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.
Cheers,
Marwan
Edited: 12 Aug 2011, 5:58 p.m. after one or more responses were posted
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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
▼
Posts: 756
Threads: 31
Joined: Aug 2010
Oops :). I will fix it. Thanks!
Posts: 756
Threads: 31
Joined: Aug 2010
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 HP12C 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).
Cheers,
Marwan
Edited: 11 Aug 2011, 8:56 p.m.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 756
Threads: 31
Joined: Aug 2010
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 HP15C manual (quoted by Tommy):
Quote:
"After digit entry termination, CHS and EEX are liftenabeling".
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 HP35 (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 HP45, HP65, and Woodstocks. Was the HP67 the first with the third implementation? BTW, the HP55 can be added to the machines that do it the second way.
Cheers,
Marwan
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 756
Threads: 31
Joined: Aug 2010
Marcus, I hear what you are saying. I have implemented an RPN simulator for the HP39gs and the hardest part to get right was the stack lift. It seems so easy and yet it is not really trivial.
Cheers,
Marwan
Posts: 1,477
Threads: 71
Joined: Jan 2005
Quote:
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.
Posts: 275
Threads: 38
Joined: Jul 2007
Quote:
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.
Quote: ...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.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
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:
Quote:
3) Pay attention to what appears to be a bug in the HP12C Platinum: negating a number just entered by pressing
the CHS (change sign) key does not work the way it used to on the classic HP12C. 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.
