Tripartite Palindromic Partition of Integer (HP 50g) Challenge

[3298]

You're evil picking such an input number, you know that?

While I haven't looked at the UserRPL program, from the proof alone I can see that it runs into one of the mentioned choose-numbers cases in the 6-digit algorithm. There it apparently disregards the non-zero digit restriction and chooses \(x_1=9\) and \(y_1=0\), causing the y palindrome to become invalid.

To fix it, I recommend implementing the "choose" part as picking (sum / 2) and (sum / 2) + (sum mod 2). As long as the sum is >=2, the chosen digits will be >=1 as well. If it isn't, the restriction can't be fulfilled anyway, and the proof obviously takes care to avoid such failures.
There are no other digit restrictions for these, so you're safe as long as you avoid accidental zeroes.

In UserRPL, the implementation could look like:

Code:

2. IDIV2 OVER +

In SysRPL it depends on the type of number you're calculating with, but it'll be a variation on the same theme - I'm using BINTs, which leads to:

Code:

BINT2 #/ SWAPOVER #+

Note that #2/ exists, but doesn't leave the remainder behind, only the quotient, so it's not suitable. Alternatively, I could do:

Code:

DUP#1+ #2/ SWAP #2/

With ZINTs instead of BINTs you'd be looking at the guts of the UserRPL command, which is appropriately named FPTR2 ^IDIV2. (We definitely don't need to handle complex numbers or symbolics here, so the extra code in FPTR2 ^STEPIDIV2 is dead weight.)