2024 HHC Programming Contest - RPN #1

[Gene]

And it was my mistake that I did not transcribe Gunters program correctly !

[Mike T.]

My own efforts for the HP33 / HP25 are not nearly as inventive as some others, and I couldn't include a label as they are not available.

First attempt

Code:


 01-      7 7
 02-     31 ENTER
 03-      7 7
 04-     31 ENTER
 05-      7 7
 06-     71 /
 07-     51 +
 08-     31 ENTER
 09-     31 ENTER
 10-     51 +
 11-     51 +
 12-  13 00 GOTO 00

Only 12 bytes thanks to the way each step is stored.

Second attempt (managed to shave off one byte from my original attempt by dividing before adding)

Code:


 01-      7 7
 02-     31 ENTER
 03-      7 7
 04-     71 /
 05-      7 7
 06-     51 +
 07-     31 ENTER
 08-     31 ENTER
 09-     51 +
 10-     51 +
 11-  13 00 GOTO 00

11 bytes...

Perhaps I'll get my x11-calc-41c code working before the next HHC Meeting!

[Allen]

(09-23-2024 11:06 PM)Paul Dale Wrote:  My best entry is:

Code:


001 LBL A
002 7.77
003 PI
004 *
005 INT
006 END

Nicely done!!

[DGM]

(09-23-2024 11:06 PM)Paul Dale Wrote:  My best entry is:

Code:


001 LBL A
002 7.77
003 PI
004 *
005 INT
006 END

I like it! However, don’t the rules say that you cannot use any numeric entry keys except the 7, three times? Wouldn’t the decimal point count as a numeric entry key in this case?

DGM

[DGM]

Oops. I read it as numeric keys, the rule says numeric digits. My bad.

DGM

[ThomasF]

(09-26-2024 07:23 PM)DGM Wrote:  Oops. I read it as numeric keys, the rule says numeric digits. My bad.

DGM

As shown before, it can be solved with only 3 numeric keys (if that was part of the rules):

LBL A
777
PI
%
INT
END

As a bonus, it only uses 11 bytes in total ...

Cheers,
Thomas

[jjohnson873]

I shared the "PI" solution with Gene during the conference and he said the "use of PI" violated the rule of no numbers other than "7". Therefore my solution was invalidated.

[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. :-)

[AnnoyedOne]

(09-27-2024 06:11 PM)jjohnson873 Wrote:  I shared the "PI" solution with Gene during the conference and he said the "use of PI" violated the rule of no numbers other than "7".

Technically correct.

pi = 3.1415926536 (approx) so it is a number. However the pi key is not a "digit" so I'd put in the same category as "." (allowable?).

That said the "judges decision is final".

A1

[Gilles]

The first thing I thought about in RPL 49-50g is

Code:

 « 7 7 7 / DUPDUP + + - ! »

@CD3, why not :

Code:

 « "77.7" SIZE ! »

[c3d]

(10-13-2024 08:51 AM)Gilles Wrote:  The first thing I thought about in RPL 49-50g is

Code:

 « 7 7 7 / DUPDUP + + - ! »

That one is 16 bytes.

Quote:@CD3, why not :

Code:

 « "77.7" SIZE ! »

That is 11 bytes too. I thought I had mentioned it, but it looks like I only mentioned the HP41 equivalent.