Motivation
My admiration for the HP-12C is largely limited to its history and status as an inexpensive collector’s curiosity1 but one feature I do admire is its %T button. Given a total pushed onto the stack as y and then a “part” as x, it returns the percentage that x is of y. For instance, three is 60% of five:
5
ENTER
3
%T
60
What I don't get is how this is a “financial” calculation, specifically. It’s useful in lots of areas, but as far as I have been able to find out, HP never gave it to us on a “scientific” calculator. It may be buried somewhere in the big graphing calculators’ menus, but I didn’t go looking there.
According to the HP-12c Platinum manual, Appendix E, the calculation is simple:
5
ENTER
3
÷
1/𝑥
100
×
I then asked a coding AI:
Write an HP-32S program labeled "T" for computing the percentage of total given the total in stack register y and the partial value in x.
It thought this was a fine solution:
LBL T ; 01: Label T
R↓ ; 02: Roll down (total goes to X, partial to Y)
÷ ; 03: Divide partial by total
100 ; 04: Enter 100
× ; 05: Multiply by 100 for percentage
RTN ; 06: Return
🤦♂️ It appears to consider roll-down equivalent to x≷y, but it took my gentle correction graciously and made the proper fix.
Another thing we need to take care of is the portability problem. With an older calculator like the HP-15C, each keystroke is stored as an instruction, no matter how trivial, so the naïve way of adding 100 to your program as a constant takes 3 instructions. You can instead press EEX without giving it a multiplier, then “2” for the power-of-10 exponent to get “100” in 2 instructions because the multiplier defaults to 1, and 1⨉10²=100. My DM32 appears to be able to hold the “100” constant as a single instruction, but I don't know if that is an HP-32SII extension to the 15C behavior or if the older 32S had that ability, too.
Once I fixed up all the comments, the result is straightforward and satisfactory:
LBL T ; 01: percent of the total (%T) in Y, with partial value in X
x<>y ; 02: swap total into X, partial into Y
÷ ; 03: get decimal form of answer
EEX ; 04: input a power-of-10 value...
2 ; 05: ...with exponent 2 = 100
× ; 06: multiply to get percentage
RTN ; 07: return %T in X
There is an even more efficient form due to “tony(nz)” on the old HP Museum forum in post #9 of this thread:
LBL T ; 01: percent of the total (%T) in Y, with partial value in X
1/𝑥 ; 02: take reciprocal of partial input
% ; 03: (1/partial)% of total = (1/partial)/100 × (total) = total/(100*partial)
1/𝑥 ; 04: flip that to give the intended calculation
RTN ; 05: return %T in X
Step 3 is where the magic happens, and I confess to needing the AI to explain it to me before I could comment it properly.
Brilliant! We went from eight instructions for the naïve version down to five. The cost is that it involves three expensive division operations, making it slower to run and potentially less accurate than my version, which does the job using one division and one multiplication. For the example problem, you can see the loss of precision in FIX 8 mode and beyond; below this point, the calculator’s rounding behavior hides the error. The bigger version above doesn’t have this weakness.
There is one other difference to be aware of: the memory-optimized version leaves the “total” input value behind on the stack in y, whereas my "EEX 2" version above consumes both arguments. Which is better? To my surprise, the HP 12C version of %T does it the first way even though the other basic 2-argument functions on that calculator (e.g. +) consume both arguments. I think that makes more sense, but it has been argued that one might wish to perform subsequent actions on the total, making the 12C correct to leave it behind in y.
That gives us my DM32 state file version which matches the 12C API and accuracy, at a cost of 8 instructions.
Bonus Round
Later, I decided to try converting these to a form the 20S needs. I started with the “straightforward and satisfactory” algorithm,:
LBL A ; 01: Usage: total INPUT partial XEQ A
STO 1 ; 02: Save second input, the 'partial' value
SWAP ; 03: Bring 'total' input into the display register
÷ ; 04: This is algebraic, so divide the total by…
RCL 1 ; 05: …the partial value…
= ; 06: …giving the inverse of the ratio we actually want.
1/x ; 07: Flip it right-side up.
⨉ ; 08: The 20S is old-school…
E ; 09: …lacking inline constants…
2 ; 10: …making multiplication by 100…
= ; 11: …painful!
RTN ; 12: yield result
Algebraic entry has nearly doubled the instruction count above, and it eats a storage register (#1) besides because it cannot rely on the stack; SWAP on a 20S is context-dependent, making it not quite the same thing as the RPN machines’ x≷y. In this instance, it means we cannot avoid the need for the reciprocal command by delaying the swap. That in turn means we lose precision due to needing two division operations.
If we have to accept that loss, can we at least regain some memory by doing it the clever way?
LBL A ; 01: Usage: total INPUT partial XEQ A
SWAP ; 02: Lacking a stack, we have to play games with INPUT.
STO 1 ; 03: Save total for later.
SWAP ; 04: Bring partial input back.
1/x ; 05: Step 1 of the memory-optimized algorithm.
⨉ ; 06: Step 2: % is a 1-input function on the 20S so…
RCL 1 ; 07: …we must bring the total back here and…
% ; 08: …turn it into a raw percentage which we…
= ; 09: …can at last multiply by the partial!
1/x ; 10: Step 3 of the memory-optimized algorithm.
RTN ; 11: Yield result in display register.
One whole instruction saved, making it over twice as long as the 32S version above.
And this is why we like RPN.
Credits
Further credits for improvements to this article since its original version go to the participants in this HP Forums thread.
License
This work is © 2025 by Warren Young and is licensed under CC BY-NC-SA 4.0
- ^ The greater part of my interest is in the scientific side of the calculator world.