Tripartite Palindromic Partition of Integer (HP 50g) Challenge

[3298]

I followed the steps in the proof for that input number by hand, and it looks like an issue with the proof, not a particular implementation of its algorithm.

92805 is a 5-digit number with something other than 1 as most significant digit ...

The proof Wrote:then \(n\) is of type A and we apply Algorithm I, which works for \(m = 2\).

More precisely, it's type A3 with \(x_1=8, y_1=9, z_1=8\). The carry from that column is \(c_1=(8+9+8)/10=25/10=2\). Applying step 2 gets us \(x_2=2, y_2=9, z_2=7\), with a carry of \(c_2=(2+9+7+2)/10=20/10=2\). The loop designed into Algorithm I doesn't get to run at all with \(m=2\), so we head straight to the final pre-correction step setting \(x_3=0\). That is, our palindromes start out as 82028, 9999, and 878.

Next, the correction step, which is where it gets spicy. \(c_2=2\) leads us into case I.3, which makes some arguments:

The proof Wrote:In this case, we have that \(y_m \neq 0\) (otherwise \(c_m \neq 2\)). Further, if \(z_m \neq g-1\), then the only possibility to have \(c_m = 2\) is that \(z_m = g-2\), \(y_m = g-1\), \(x_m = 1\) and \(c_{m-1} = 2\), but that gives \(\delta_{m-1} = 0\), which is not allowed. Thus, \(z_m = g - 1\) and we make the following adjustment:

The most obvious problem here is the final conclusion: \(z_m\) is not \(g-1\) (that would be 9 in decimal mode), but 7 instead.
But the problems really start earlier than that, because unlike with greater \(m\), we have the possibility to see an \(x_m\) greater than \(1\) thanks to the algorithm's main loop not running even once. Indeed, we have \(x_2 = 2\). Additionally, we do have \(\delta_{m-1}=\delta_1=0\), despite the proof saying that is "not allowed" (I don't understand enough of it to know where that is coming from; maybe that conclusion is also invalidated by \(x_2=2\) or its root cause, \(m=2\)).

The bottom line is, I don't know how to fix it. Blindly applying the proof's correction of setting \(x_3\) to \(1\), decrementing \(y_2\), and setting \(z_2\) to \(0\) is how you receive the result you did, so the implementation appears to behave as the (buggy) specification says. For this particular number, decrementing \(y_2\) by an additional \(2\) and incrementing \(x_3\) by the same does yield a valid sum (the \(2\) comes from by how much \(z_2\) was off compared to the expected \(g-1\)), but I can't tell if such a fix breaks on another number without a deeper understanding of the math.