2023 HHC RPL Programming Contest
|
10-07-2023, 01:01 PM
Post: #1
|
|||
|
|||
2023 HHC RPL Programming Contest
Please DO NOT POST solutions here until after 6pm EASTERN time Sunday 10/8/2023.
|
|||
10-08-2023, 11:20 PM
Post: #2
|
|||
|
|||
RE: 2023 HHC RPL Programming Contest
I have 3 versions, tested on the HP 50G
solution = 381654729 First solution Code:
Second solution using user flags Code:
Third solution using the user flags, restoring it at the end of the program Code:
-Edwin- |
|||
10-09-2023, 11:02 AM
(This post was last modified: 10-09-2023 11:04 AM by 3298.)
Post: #3
|
|||
|
|||
RE: 2023 HHC RPL Programming Contest
This challenge is an old one, and I remember the previous iteration pretty well as Albert Chan and I made it more spicy by running off with a variant generalized to base-N. For the original one my size-optimized UserRPL take (in post #10) was 203.5 bytes long. I also had a speed-optimized one, due to different scoring criteria. The SysRPL programs in the same post were superseded by my 145-byte improvement (in post #15). That post is also where I kicked off the base-N race.
The smallest UserRPL submission was by C.Ret (in post #11) at 147.5 or 139.5 bytes, depending on whether it's entered in approximate or exact mode. It was designed for compatibility all the way down to 28C/28S, which didn't have exact mode. On machines with this mode both variants of the program work properly, the only differences are small changes in size and speed. C.Ret also came up with a much faster program later, but it wasn't as small. It also requires exact mode on machines that have it, otherwise the trailing period added to reals in \->STR breaks the program. I informed Gene about this repeated challenge via PM to let him take whatever action he deems appropriate, and he replied that it was an accident facilitated by a hard drive crash erasing his files on that puzzle. The on-site participants apparently didn't remember the previous iteration, which restores fairness. Additionally, let me mention that asking for a program taking no input at all introduces a problem: it becomes possible to pre-calculate too much (e.g. \<< 381654729. \>> is definitely not acceptable), and the line between that and acceptable programs constructing that number gets blurred. For instance, how do you feel about this? Code: \<< This topic is also not new, it already happened in 2019. In the 2021 iteration of this particular puzzle the base-N generalization added an input, preventing optimization past a certain (well-defined!) point. That and the raised difficulty kept it interesting for me for a while. Unfortunately, if we could prove the conjecture that there are no solutions for bases >14, that variant would also get optimized into a simple program regurgitating precalculated results. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 2 Guest(s)