A little classical RPN challenge


Hi everybody, here's another little challenge, this time having to do with
classical RPN, so most of you will be able to give it a think.

The Challenge:

1) Starting from this initial stack arrangement (where A, B are some arbitrary values),
to reach this final arrangement, in a minimum number of steps:

T - T -
Z - Z B
Y B -> Y B

2) Same for this other case:
             T   -              T   B
Z - Z A
Y B -> Y B

You can use any functions and operations whatsoever available in your RPN calc,
as long as you do it in a minimum number of steps, the solution asked for is the one
that delivers the goods in as few steps as possible, notwithstanding concerns of
efficiency, usability, etc. Remember, this is intended
to be challenging and fun, not necessarily practical.

For the HP-15C & HP-11C, there are several solutions in as few as three steps for
case (1) and four steps for case (2) above, and I'm confident those sames solutions are
likely to also work on an HP-34C, HP-67, HP-41C, HP-42S and many other models, though
I can't confirm it right now.

Flex your RPN muscles and give it a try ! The best answer posted within 96 hours gets (by e-mail)
a good-quality scan of a very old, very rare, frankly bizarre HP calc brochure.


Try this for #1


2 steps

But you said the 11c / 15c variety, which don't include the RCL stack command. Continuing to think...but only have a 12c handy.


For case two:


And we have it in two STEPS (four bytes, instead)

Hope this helps


Thanks for the answers for the HP-41C (also valid for the
HP42S) but of course, the challenge is for machines having
classical RPN stack but no STO/RCL/X<> functions
addressing stack registers (STO Y, RCL T, X<>Z, etc).

Else, it wouldn't be much of a challenge, indeed ...

See if you can find a minimum solution for machines such
as the HP-10C/11C/15C ..., HP-25/27/29C ..., HP-34C,
HP-67, HP-91/92/97 ..., etc, or even for the 41C/42S but
avoiding the use of stack addressing for STO/RCL/X<>


The answers would be restricted to two models, indeed.


For the first case (A B B -) I can't get it below four steps:
[ENTER] [ENTER] [+] [R Down]
I have another solution in four steps as well.

For the second case (A B A B) I have:
[f CLEAR REG] [Sum+] [RCL Sum+] [RCL Sum+]

Looking forward to seein a better solution to #1,
- Michael


THe stack after your (1) solution would be


Do the rules allow the T level of the stack to be A+B?

I took the original instructions to imply it should hold a zero or whatever it held originally.

Good solution anyway!


Hi Gene,

It wasn't specified in the rules. I took the dashes "-" as "don't-cares" whose values were unimportant. But that's just my interpretation.

- Michael



this was post a few hours ago.

But there is one problem: [CLEAR] [E+] also clears the stack registers contents in the HP11C and in many other calculators, so one should input A and B after clearing statistics registers with [f] [CLEAR] [E+].

Maybe the post is not so easy to view because it is not exactly in this branch of the original thread.


Hi Vieira,

I didn't read any of the replies before because I wanted to try it on my own without peeking at the answers, so to speak.

You're right about [CLEAR] [E+] clearing the stack. The 11C's [f CLEAR REGS] clears memory but leaves the stack untouched, so it's safe to use after the numbers are put on the stack.

Thanks for your reply.

- Michael


... that your solution is better than mine because of this: [f][CLEAR][REG] is not destructive in relation to stack contents. The fact is that your solution works everytime, mine doesn't.

Thank you.

Best regards.


Provided the calculator has [RCL][E+] (both HP41 and 42 don't have), where [E+] is the summation key, and [CLE] (Clear Statistics) is executed prior to A and B input (too much rules, I know):

[RLC][E+] (case 1 stops here)
[RLC][E+] (case 2 stops here)

With the HP55, [RCL][E+] overwrites both X- and Y-Register contents (maybe others do, I don't know) while others lift the stack one time, leaving previous Y-contents unchanged and moved up to Z-register. In the HP55, we have:

[RLC][E+] (case 1 stops here)
[RLC][E+] (case 2 stops here)

To be honest, I didn't like these solutions: needs a lot of memory (all statistical registers must be present)

But it works...


Hah! All you need for these is the right "O/S":


[2] DUP2

And having poured gasoline on the fire, I'll just step back a few, uhhh, thousand, kilometers :).


If you relax the challenge constraints (which are part of the fun), RPN does better than RPL: someone already posted



(two steps)

Within the problem constraints, I am still looking for a better way than:

0) Starting with X Y Z T = a b p q

1) Roll Down produces X Y Z T = b p q a

2) Roll Down produces X Y Z T = p q a b

3) "+" produces X Y Z T = (p+q) a b b

4) Roll Down produces X Y Z T = a b b (p+q)

... q.e.d.

Since this "hole" is Par 3, I am still one over par (4 steps), so this is a Bogey; I asume the (p+q) term in the T register does not violate the constraints.

Note that RPL, among other curses, will not allow for the automatic T register replication used in step 3, and probably will "nag" at you many times while you tinker about this challenge.


I don't have any calculator which has the "RCL E" (RCL sigma) function, but if "RCL E" has the effect of pushing the stack two levels up; then my previous example could be converted in:

0) Start with X Y Z T = a b p q

1) RCL E produces X Y Z T = v w a b,

where v and w are the contents of the x-sum and y-sum registers, which value doesn't matter, the only issue is to push the stack two levels up.

2) "+" produces X Y Z T = (v+w) a b b,

due to T register replication feature of RPN

3) Roll Down produces X Y Z T = a b b (v+w)

... q. e. d. in 3 steps

This will not work in my late HP25, nor in my HP41 or HP42; but perhaps it does in the HP11, 15, etc...


Hi Andrés,

Good solution! It does work on the 11C.

- Michael



2) E+,

Note that after the Sigma instruction, Y is preserved, X is replaced by a count, which in this case will be 1, and stack lift is NOT enabled...


In an HP25, it would take two steps: RCL 4 and RCL 7...

Actually, if cleared registers could be assumed as a starting point, it could be one less step (Birdie)


Hola, Andrés;

as posted by Michael, [f][CLEAR][REG] is better because [f][CLEAR][SIGMA] will clear stack registers' contents in almost all RPN calculators. And both HP41 and HP42 do not have a [RCL][SIGMA+], what is too bad!.

Best regards, my friend. Good reading your posts again.


Luiz: Thank you for your greetings, I have been very busy in the last weeks.

At least in my limited experience, CLEAR SIGMA should not affect the stack contents; in fact, in the very good HP41 emulator I have in my PDA it keeps the stack untouched; later today I will check in my "real" HP41C and HP42S, but I don't have them at hand right now. I cannot think there is a reason for CLEAR SIGMA to clear the stack...


I have tried a friend's HP27 (Woodstock), my HP41C, my HP42S, my daughter's HP32Sii, and also eV41 on my HP/Compaq WindowsCE-based PDA, and have not found an example of CLEAR SIGMA affecting the stack contents....


Hola, Andrés;

you are correct: CLEAR [SIGMA] clears stack contents of all Voyagers (the worst case is the HP12C where CLEAR REG clears everything but programs) and I also tested in the HP55 (classical) and the stack is cleared with any of both: CLR and CL.R. Both HP67 and 97 do not have an specific CLEAR [SIGMA] and CLREG is used so far. In the HP41 and HP42 it does not happen because they have CLST, not available in any voyager. I do not know about the HP27 and the HP32SII.

What I still wonder about is the LASTx contents: the only one I tested that effectively has LASTx contents cleared after CLEAR REG is the HP12C. I did not test all of them, but all other Voyagers, any HP41, the HP42 and the HP55 keep LASTX contents after any clearing function.




On the HP 27, clear sigma does not clear the stack. Neither does that function clear the stack on the 32S and 32SII.



I have a Woodstock HP27 in hands (does not belong to me) I just brought back to life and I looked at the keyboard and saw a [CLEAR][STK] ([f][CLx]), what explains the fact that [CLEAR][SIGMA] keeps stack contents unchanged. Also I remember the HP32S has the ST option at the CLEAR menu; maybe the HP32SII has this option, too.

I believe that, with a few exceptions, calculators that have a [CLEAR][STACK] command/function have the stack contents unchanged when [CLEAR][SIGMA], if available, is performed. As none of the Voyagers have a [CLEAR][STACK] command/function, [CLEAR][SIGMA] also performs a [CLEAR][STACK]. As for the classic models, I can only speak for the HP55, that has the stack contents cleared after CL.R or CLR. In the HP67 manual, p. 80, it's explained that the user should enter 0 and press [ENTER^] three times to clear the entire stack and that [f][CL REG] does not affect its contents.

Wow! That's what I call a thread to exhaust a particular theme.



Thank you, I liked your solution to #2


Maybe someone can program a solution to the general problem in fewer steps?

Given any values in x, y, z, t & last x, return the four stack registers with any of those values present in any arbitrary sequence of selection and/or repetition, as specified by the user (or with slight adaptation, by another program).

    A01  LBL A        "XEQ A" to start "The Scrambler"

A02 STO B x will be referred to by "1"
A03 Roll Down access y
A04 STO C y will be referred to by "2"
A05 Roll Down access z
A06 STO D z will be referred to by "3"
A07 Roll Down access t
A08 STO E t will be referred to by "4"

A09 last x access last x
A10 STO F last x will be referred to by "5"
A11 STO G . . . or "6"
A12 STO H . . . or "7"
A13 STO I . . . or "8"
A14 STO J . . . or "9".

A15 0 access zero
A16 STO A zero will be indexed as "0"

A17 INPUT V input the desired sequence vector
A18 RCL V first,
A19 ABS insure not negative
A20 IP and no fractional part
A21 STO V in vector.

A22 XEQ V obtain specified t value
A23 XEQ V obtain specified z value
A24 XEQ V obtain specified y value
A25 XEQ V obtain specified x value


V01 LBL V use low-order digit of V to obtain next register

V02 10 need ten to obtain a digit
V03 STO / V shift V one digit right
V04 STO i and preset index register
V05 ROLL DOWN keep stack from overflowing

V06 RCL V obtain shifted vector
V07 FP reduce to newly-obtained digit
V08 STO - V and remove that from V
V09 STO * i while restoring it as an integer
V10 ROLL DOWN prevent stack overflow

V11 1 need to increment index by 1
V12 STO + i to keep from (unfortunate) error
V13 ROLL DOWN prevent stack overflow

V14 RCL (i) recover next value desired


With any values in the stack & last x, XEQ A.

It'll prompt for a “V” value.

Enter four digits in x, y, z, t sequence, specifying any desired choice of register values using the following encoding:

   0 == zero (cleared)
1 == original x value
2 == original y value
3 == original z value
4 == original t value
5-9 == original last x value

Whatever is entered (I hope!), the low-order four digits of the integer portion are interpreted as a specification of which values are wanted where, and the stack is returned in the condition so indicated.

This was programmed on an HP-32SII, and (if I’ve transcribed everything correctly) “MEM” shows LBL A = 39.0 bytes, LBL V = 22.5 .

With a few demands added regarding proper user behavior, some of the normalization and error prevention lines could be removed . Deleting lines A11-14 and A18-21 reduces the LBL A footprint to 27.0 bytes. (This, then, requires the user to enter a positive integer, and to use only codes “0”-“5”.)

To make it work as a subroutine (who on earth would bother?), simply delete line A17 and XEQ A from elsewhere.

And . . .

with regard to the two special cases posed by Ex-PPC member, one would XEQ A and enter “122n” (where “n” is any decimal digit) to achieve the first, or “1212” to satisfy the second.

-- "It is thus", cried Alexander, "that I untie all Gordian knots!"


I accidentally discovered this last night, present it for mutual amusement. I don't consider it a "real" solution to the presented problem, but instead more of a disclosure of an incompletely presented RPN (by HP, no less! :).

I recently got a 17Bii from Randy Sloyer (THANKS!), and it differs from a 17B primarily in having RPN (so they say, but read on). So carefully follow the bread crumbs below to See What Happens:

[A] Shift MODES RPN ---> see RPN MODE

[B] Shift CLEAR DATA ---> 0.00

[C] ( ( ( ( ---> 0.00 repeated, just like you'd expect; note that in RPN mode, "(" is the Stack Roll Down.

[D] 4 INPUT 3 INPUT 2 INPUT 1 ( ( ( ( ---> yept, Life Is Good, see 1.00, 2.00, 3.00, & 4.00

[E] v & ^ ---> Roll Down & Roll Up work just like we're familiar with; note these are the all-purpose roll keys between the Shift and the INPUT keys.

[F] Shift CLEAR DATA 1 v v v ---> hmmm, all we see are 1.00, this doesn't seem right.

[G] Shift CLEAR DATA 2 INPUT 1 v v v v v ---> alternating 2.00 & 1.00, _no_ zeros.

[H] Shift CLEAR DATA 3 INPUT 2 INPUT 1 v v v v v ---> 2.00, 3.00, 1.00, 2.00, 3.00 ..., and this is beginning to make sense (^ gives you the opposite sense, confirms the stack roll goes up too).

So [F] through [H] show you that the stack is not a constant four levels TZYX, but instead starts out at one level, and is "populated" as appropriate.

[I] Shift CLEAR DATA ) 1 v v v v v ---> 0.00, 0.00, 1.00, 0.00, 0.00, 1.00 ...; ")" or X<>Y seems to be the exception, SWAP populates levels 1 & 2 (RPL terminology seems more appropriate now), and a numeric entry pushes them up to 2 & 3.

Having now presented the rationale (and examples for those not endowed with a 17Bii), I present a three-step, stack-only solution to the original problem [1] B A ---> B B A:

Shift CLEAR DATA "B" INPUT "A" ---> Setup of initial conditions; we now have a two-stack, B over A.

^ or v or ( ---> we now have a two-stack, A over B

INPUT ---> three-stack, A over B over B

^ ---> voila!, B over B over A (and indeed, we don't care about the "T" register, it's not yet been "invented".

[J] + + + + + + v v v v v ^ ^ ^ ^ ---> 8.00 repeated (remember, we're coming from the Z:3 Y:3 X:2 of above, and I use those "levels" loosely); those two additions appear to "consume" levels 3 & 2, so that we're left only with level 1 (not exactly RPL behavior, the third "+" would error with it).

This experiment appears to suggest an alternate and cleaner view, that we really are adding repeatedly "0.00" to X, and that we really have an empty T-register (and four stack levels, whew, we're back to RPN). However, there's a "Roll-Stack Population Register" somewhere that advises the roll keys how high to roll. On a true RPN this would always be "four", but on a 17Bii it apparently can be anything between one and four.

[K] 4 INPUT 3 INPUT 2 INPUT 1 + + + + + + + + ---> 3.00, 6.00, 10.00, 14.00, 18.00, 22.00 ...; now *this* is our familiar T-register (RPN) behavior.

Conclusion: Until you have all four levels populated (that is, your Roll-Stack Population Register is four), don't trust your 17Bii to Roll in true RPN fashion.

Perhaps somebody with a 19Bii can advise how faithful its RPN behavior is.

P.S. My hat's off to Paul Brogger for his "Re: RPN challenge -- Not quite 3 steps, but a solution to the general problem . . . ", most amazing. As I don't have a true RPN (and 17Bii's don't do procedural programming anyway), I can't test it, only admire it.


Hi, Glen;

Yes, the HP17BII (and the HP19BII as well) have a 1-to-4 level stack. It may contain from one to four numbers stored on it,and when you clear it, it will contain only one register - the X-register - with a [0.00 ]. Try this:

[][CLEAR DATA]          ([] is the shift key)
0 [INPUT][INPUT][INPUT] 4 (any number)

What do you see? You now have the four stack-registers. If you simply clear data and enter 4 (any number), there will be only the X-register and the number 4.00 stored in there.

If you enter only three numbers, [(] (or roll-down) will roll only these three registers. And it happens the same in the HP19BII.

There is a small book that came with my HP19BII only to explain RPN and the differences between the HP19B and the HP19BII. I can scan it (it's just a few pages) but I must tell you it's written in Spanish.


Possibly Related Threads…
Thread Author Replies Views Last Post
  [PRIME] RPN: another attempt at returning more than one value to the RPN stack Marcus von Cube, Germany 5 2,466 11-05-2013, 02:44 AM
Last Post: Marcus von Cube, Germany
  HHC 2013 RPN Programming Challenge - Final Thought Jeff O. 7 2,370 10-17-2013, 11:02 AM
Last Post: Jeff O.
  HHC 2012 RPN Programming Challenge Conundrum Jeff O. 15 4,077 10-08-2012, 03:34 PM
Last Post: Gerson W. Barbosa
  Mini challenge. CEIL / FLOOR in RPN M. Joury 47 10,953 10-31-2011, 10:11 AM
Last Post: M. Joury
  OT: A Turing machine in the classical style Juergen Keller 3 1,347 05-01-2010, 02:16 AM
Last Post: Juergen Keller
  New Iphone & Itouch calculator - Access RPN and Active RPN Nigel Bamber 1 1,155 06-10-2009, 04:13 PM
Last Post: Jean-Michel
  Another calculator with RPN (Corvus 500 RPN) Saile (Brazil) 7 2,206 03-31-2009, 12:14 AM
Last Post: Michael de Estrada
  RE: 35s sorting routine challenge - Gene's Challenge Miguel Toro 4 1,590 08-01-2007, 08:36 AM
Last Post: Miguel Toro
  Platinun × Classical Voyagers: new LCD images Vieira, Luiz C. (Brazil) 4 1,337 06-16-2003, 12:51 AM
Last Post: Michael F. Coyle
  HP-41 / 42 style RPN challenge Gene 13 3,177 02-13-2003, 10:12 AM
Last Post: Paul Brogger

Forum Jump: