HP 12c Platinum Error 0 in Percent Difference

[Kaijikunito]

http://h10032.www1.hp.com/ctg/Manual/bpia5184
2005 User Manual
Appendix B: Algebraic Mode (AlG) p. 241

I recently acquired an HP 12c Platinum calculator (I miss the gold plate!) and I am doing a read-through of the manual in order to understand how to use it.

On page 241 of the manual, the following instructions are given:

"To find the percent difference between two numbers:
1. Key in the base number.
2. Press [-] to separate the other number from the base number.
3. Key in the other number.
4. Press [change %]

Example: Yesterday your stock fell from 35.5 to 31.25 per share. What is the
percent change?

Keystrokes
(ALG mode) Display
[CLX] [CLX] 0.00 Clears any pending operations.
35.5 - 35.50 Keys in the base number and separates it from the other
number.
31.25 31.25 Keys in the other number.
[change %] -11.97 Nearly a 12% decrease."

I perform [f] [REG] before attempting these calculations. When I follow the above instructions, I receive an Error 0 display, which occurs when y = 0.
Note: In RPN, this yields -188.03. ***

I also receive the Error 0 display when I follow the above instructions with an added [ENTER] after 31.25. Thus:
35.5 - 31.25 ENTER change% = Error 0
Note: Occasionally when I perform these keystrokes, -88.03 is displayed
but I cannot consistently replicate this result. ***
Note: in RPN, this yields 0.

I would like to note that when I perform the following two sets of keystrokes in Algebraic mode, I receive the correct answer. This leads me to question whether [-] can always be substituted for [ENTER], as stated in the manual:

35.5 ENTER 31.25 - change% = -11.97
Note: These keystrokes yield an Error 0 display in RPN. ***

35.5 ENTER 31.25 change% = -11.97
Note: These keystrokes yield the same result in RPN.

So my question is, am I doing something wrong or misunderstanding the instructions?

Although I understand that RPN mode requires different keystrokes than ALG mode,
I am curious as to where the answers -188.03 , -88.03 and Error 0 come from in my RPN notes (marked with ***) so that I can better understand the stack.

[Gamo]

I try this problem and see no issue.

Example: 35.5 to 31.25 What is the percent change?

--------------------------------------------

RPN mode

35.5 [ENTER] 31.25 [∆%] --> -11.97

--------------------------------------------

ALG mode

35.5 [=] 31.25 [∆%] --> -11.97

--------------------------------------------

For people who getting used to the RPN logic sometime
get confuse on how to perform functions on ALG mode.


Gamo

[Dieter]

(11-02-2018 03:00 AM)Kaijikunito Wrote:  On page 241 of the manual, the following instructions are given:

"To find the percent difference between two numbers:
1. Key in the base number.
2. Press [-] to separate the other number from the base number.
3. Key in the other number.
4. Press [change %]

You have misread the second point. It says
"2. Press [=] to separate the other number from the base number."

It's the "equals"-key, not "minus" !

Simply type the first number, press [ENTER] or [=] (it's the same key!), type the second number and press [Δ%]. Just as the manual says, exactly as in Gamo's example. Do not add any other keys like additional [ENTER]s or [–] or whatever.

BTW, the results of –188,03 or –88,03 mode can be easily explained. This is due to your additional [–]. This way you are calculating the percentual change from 35,5 to (35,5–31,25) which is –88,03%. Likewise, the change from –35,5 to 31,25 is –188,03%.

Problem solved?

Edit: Lunch break! So here is a more detailled analysis:

(11-02-2018 03:00 AM)Kaijikunito Wrote:  I also receive the Error 0 display when I follow the above instructions with an added [ENTER] after 31.25. Thus:
35.5 - 31.25 ENTER change% = Error 0
Note: Occasionally when I perform these keystrokes, -88.03 is displayed
but I cannot consistently replicate this result. ***
Note: in RPN, this yields 0.

Yes, of course. 35,5 – 31,25 ENTER is a normal calculation in ALG more. Remember: ENTER is the "=" key! So you are simply calculating 35,5–31,25=4,25. If you now press [Δ%] there is no base number (all you got is 4,25). More exactly: because of your CLX before the base number is zero – and therefore the attempt of calculating the change from 0 to 4,25 certainly returns an error.

In RPN mode (starting with a zeroed stack) the same key sequence first calculates 0–35,5 = –35,5. After entering 31,25 the following [ENTER] copies this number to Y so that now both X and Y are equal. This means that [Δ%] calculates the change from 31,25 to 31,25, which is zero.

Next case:

(11-02-2018 03:00 AM)Kaijikunito Wrote:  When I follow the above instructions, I receive an Error 0 display, which occurs when y = 0.
Note: In RPN, this yields -188.03. ***

Yes. Pressing 35,5 [–] in RPN mode simply calculates whatever is in Y (here: zero) minus 35,5, so you get –35,5 first. If you now continue with 31,25 [Δ%] you calculate the change from –35,5 to 31,25 which is –188,03%.

(11-02-2018 03:00 AM)Kaijikunito Wrote:  35.5 ENTER 31.25 - change% = -11.97
Note: These keystrokes yield an Error 0 display in RPN. ***

In ALG mode the [–] preceding [Δ%] makes no sense so that it is ignored. So the calculator recognizes 35,5 [ENTER] 31,25 [Δ%] which is the correct way of calculating the change as –11,97%.
In RPN mode the [–] simply does a subtraction. So you first calculate 35,5–31,25=4,25. After this [Δ%] calculates the change from whatever happens to be in the Y-register to 4,25. Because of your previous CLX, Y again is zero, so you try to calculate the change from 0 to 4,25 – which once again throws an error.

So it all makes perfect sense.
Solution: simply do it as the manual says. Do not press any additional keys that will change what you're calculating.
In either mode, simply type base number [ENTER/=] other number [Δ%].

And finally: I see this is your first post – welcome to the forum. ;-)

Dieter

[Kaijikunito]

Oh my gosh. I read those instructions over and over. My PDF viewer was so zoomed out that the equals sign looked like a minus sign. I feel absurd.

Thank you for the clarity! I sure feel silly.

[Gene]

Don't feel silly.

The 12cp key font used when we were editing that owners manual to add the algebraic functions was not the best. I wish the = and a few other symbols had been better designed.

That said, the first 12cp owners manual did not include **any** examples of how to use the algebraic mode at all. Now as an RPN enthusiast, that was not a big deal to me, but some HP customers may attempt to use it in algebraic mode :-) and we convinced HP it should be added for keystrokes, programs, etc.

The appendix is a particularly interesting read, especially the write-up on LstX and the history stack in algebraic mode. Thanks to Tony Hutchins for his efforts in those complicated areas.

Be sure to download the 12c platinum solutions book with algebraic program versions from the manual as well as for the original RPN programs that were included in the solutions book. Here's a good place to download it.

HP 12c solutions book PDF with algebraic and RPN

That PDF should be copied and made easily available to some other people...

[Kaijikunito]

Gene,

From my understanding RPN is more efficient in terms of keystrokes, which is why I am interested in learning the sytem. I appreciate that algebraic mode is available because if I am not sure that I am entering a calculation in RPN correctly, I can double-check myself in ALG mode.

Thank you so much for posting that solutions manual! I will soon be posting it to every tree in my neighborhood to spread the word

[Zaphod]

(11-04-2018 06:15 PM)Kaijikunito Wrote:  From my understanding RPN is more efficient in terms of keystrokes, which is why I am interested in learning the sytem. I appreciate that algebraic mode is available because if I am not sure that I am entering a calculation in RPN correctly, I can double-check myself in ALG mode.

Once you’ve done a bit in RPN you’ll soon realise you’ll feel more confident that your RPN answer will come out with the right answer because you’re less likely to get muddled up with brackets entering a calculation like you might on a non-RPN Calc.

Try (13+3)÷(4×2) for instance in both modes

[jonese]

After a LONG while, you'll find that you stumble when using a non-RPN calculator. You'll be start entering RPN keystrokes, realize you can't and then start from the beginning again carefully using algebraic keystrokes instead.

At least that's my experience.

[Kaijikunito]

The more I use RPN the more cumbersome ALG mode seems. I am pretty new to using calculators in general though, outside of high school math classes some decade ago.

For example, yesterday I was trying calculate what the likelihood was of a response in chess relative to the total responses. First I summed the number of times all responses were used to find the total, and for the life of me I couldn't figure out how to then divide the number of times a particular response occurred by the total. It wasn't until today that I remembered that I can actually store numbers... >.<!

[Dieter]

(11-04-2018 07:22 PM)Kaijikunito Wrote:  For example, yesterday I was trying calculate what the likelihood was of a response in chess relative to the total responses. First I summed the number of times all responses were used to find the total, and for the life of me I couldn't figure out how to then divide the number of times a particular response occurred by the total. It wasn't until today that I remembered that I can actually store numbers... >.<!

You will soon find out that with RPN – in most cases – you don't have to store any intermediate results. In this case, for instance, the [X<>Y] key does the trick. If your total is, say, 12345 and you now want to divide 789 by the displayed 12345, simply enter 789 (pressing the divide key now would do the division the wrong way round) and then press [X<>Y]. Voilà, your 12345 is back again, you have swapped dividend and divisor, and the divide key will give you the desired result.

Dieter

[Kaijikunito]

(11-04-2018 09:05 PM)Dieter Wrote:  You will soon find out that with RPN – in most cases – you don't have to store any intermediate results. In this case, for instance, the [X<>Y] key does the trick.

Neato! Thank you, Dieter ^_^