2024 HHC Programming Contest - RPN #1

[c3d]

I found this thread quite amusing, and while it's a bit off-topic (although I propose a possible 10-byte solution at the end), I thought that I would compare how much space DB48X uses for the various solutions (since I have been focusing a lot on making it more space-efficient that HP's own RPL implementation).

First, let me start by cheating with a 10 bytes solution:

Code:


« 777 'Precision' RCL »

This is clearly cheating because it takes advantage of the fact that the default precision for DB48X is 24 digits. I think I should also add a rule that the stack at end must ONLY contain 24, so the 777 leftover in that case causes it to fail. But I'll show at end that there are more interesting ways to achieve that result that are probably legit.

(09-23-2024 11:04 AM)Gene Wrote:  Here are the solutions from the conference:

17 bytes:

LBL A 7 e^X SQRT INT 7 - 7 ENTER / ENTER + - END

DB48X equivalent is 18 bytes

Code:


« 7 exp sqrt ip 7 - 7 dup / dup + - »

As a comparison point, it's 40 bytes on the HP50G.

Quote:16 bytes:

LBL A 7 ENTER 7 ENTER 7 + + LN LASTX + INT END

DB48X equivalent is also 16 bytes (here we don't need "DUP" for ENTER since it's only used to separate values):

Code:


« 7 7 7 + + ln lastx + ip »

Quote:LBL A CLΣ Σ+ Σ+ Σ+ ENTER 7 + 7 + 7 + END

I think this one is really a 15 bytes answer on the 41, because the rules talk about a clean state, so the initial CLΣ is not necessary. This one also reminded me that Σ+ suppresses stack lift, so the ENTER is not optional. This solution does not exactly work on DB48X, because it relies on implicit zeroes on the stack, which does not work in RPL. An equivalent RPL program therefore diverges too much from the original to be really meaningful, although the following 19-bytes program is relatively close in spirit:

Code:


« 7 Σ+ 7 Σ+ 7 Σ+ Total ΣSize + »

Quote:LBL A 7 ENTER 7 + 7 + STO Y LASTX / + END

This one is a bit tricky, because there is no direct equivalent to STO Y. A relatively close approximation are the 17 bytes and 16 bytes programs below:

Code:


« 7 7 + 7 + lastx / lastarg drop + » @ 17 bytes
« 7 7 + 7 + lastx over swap / + » @ 16 bytes

Quote:14 bytes:

LBL A 7 ENTER 7 ÷ 7 % ATAN INT FACT END

The 16-bytes most straight equivalent of this one fails in an interesting way: the ip function complains about a bad argument type because by default atan returns a number with a unit (in my case, 4.004 degrees), and IP does not like that.

Code:


« 7 7 / 7 % atan ip fact » @ 16 bytes, but fails
« 7 7 / 7 % atan uval ip fact » @ 18 bytes, succeeds

Quote:LBL A 7 ENTER 77 LN INT * LASTX - END

This one is straightforward, and 13 bytes on DB48X. This is one of the few cases where the DB48X version is actually shorter.

Code:


« 7 77 ln ip * lastx - »

Quote:13 bytes:

LBL A 777 ENTER COS % INT FACT END

Also 13 bytes on DB48X:

Code:


« 777 dup cos % ip fact »

Quote:LBL A 7 ENTER 7 + 7 ÷ x^2 FACT END

Also 13 bytes on DB48X:

Code:


« 7 7 + 7 / sq fact »

Quote:LBL A 77 ENTER 7 P->R e^x INT FACT

This one is interesting because DB48X has real complex numbers, both in polar and rectangular form. So the closest approximation would be the following 16-bytes program that takes the real part of a polar number, which uses the same mathematical logic if not the same functions.

Code:


« 7∡77 re exp ip fact »

Quote:12 bytes:

LBL A COS ATAN 7 - 7 - 7 - END

Two issues here. First, COS relies on the default stack value being zero, but that does not work for RPL, where the default stack is empty. Second is atan returning a unit value so that the following "7 -" gives an "Inconsistent units" error. In order to generate the initial zero, I need to add a non-numerical zero producer. DEPTH is a good candidate, with the caveat that the program no longer works correctly if the initial stack is not empty (just like the solution above does not work if the stack contains 1 instead of 0.). In order to address the unit problem, I need to add an UVAL command. This results in a 16-bytes program.

Code:


« depth cos atan uval 7 - 7 - 7 - »

Quote:LBL A 7 Sigma+ 7 Sigma+ 7 Sigma+ RCL 11 END

This one does not work for me. As others pointed out, I think you need to replace the final RCL11 with ENTER RCL11 +. As pointed out earlier, the closest DB48X equivalent I can think of is 19 bytes:

Code:


« 7 Σ+ 7 Σ+ 7 Σ+ Total ΣSize + »

Quote:LBL A 777 LOG INT x^2 FACT END

This is another scenario where DB48X is slightly shorter, with only 11 bytes for:

Code:


« 777 log10 ip sq fact »

Quote:LBL A 77 TAN INT FACT 7 X<>Y END

This one is also 12 bytes on DB48X, where I replaced X<>Y with DROP instead of SWAP, because of my requirement that only 24 be left on the stack (otherwise I have a leftover 7).

Code:


« 77 tan ip fact 7 drop »

Quote:LBL A 777 LOG LOG ATAN INT END

With the additional UVAL required to get rid of the unit out of ATAN, this leads to a 12-bytes program:

Code:


« 777 log10 log10 atan uval ip »

Quote:LBL A 77.7 TAN INT FACT END

This one is only 9 bytes on DB48X, making it a winner in this little contest.

Code:


« 77.7 tan ip fact » @ 9 bytes WINNER

Quote:What I love are the wide varieties of the solutions. P->R ? OCT ? :-)

Is there an 11 byte solution given the LBL A and END ?

Now for the pure DB48X solutions to the problem:

Here is a 11-bytes solution that looks somewhat legit to me:

Code:


« 77.7 →Text Size x! »

Is ALENG allowed in the contest? If so, what is the size of the following on an HP41? On the HP42, I think that it's 10 bytes, but I don't remember how you get the program size on the HP41, so I'm not sure I am counting right.

Code:


LBL A "77.7" ALENG FACT END

On DB48X, I found another 10-bytes solution that I don't like because it relies on internal details and leaves garbage on the stack behind the expected 24:

Code:


« 777 sq bytes fact »

So I'd say that the current winner so far is 9 bytes:

Code:


« 77.7 tan ip fact »

Can we improve over that?

Conclusion: I was mostly interested in seeing how DB48X would compare to the HP41 here, because one of my design objectives for that project was to have an RPL implementation that was, memory-wise, closer to historical HP calculators than to HP's RPL, which old timers like me may remember as a horrible memory hog compared to earlier RPN models.

It looks like that so far, that particular goal is reasonably well achieved. :-)