HHC 2016 RPL Programming Contest

[DavidM]

(09-19-2016 04:26 AM)Wes Loewer Wrote:  Here's my 50g entry weighing in at 76.5 bytes, but with a qualification...

Wes, your code is very efficient and I'd be surprised if the official winner was significantly shorter. Thanks for using NIP -- I don't use UserRPL much these days and had to look that one up. Nice to know that there's a SWAPDROP for UserRPL!

As for the SREV, on my 2.15 50g it's not available after a factory reset unless you attach LIB 256. So at worst, you could include "256 ATTACH" at the beginning of your code. A few more bytes, but it still seems to fit the criteria as defined (perhaps Gene will chime in on this).

(09-19-2016 02:10 PM)3298 Wrote:  ...I'm more experienced in SysRPL, so I'll post that one instead. 40 bytes...

I had a hard time taking SysRPL out of my head for this problem as well, and you used most of the same commands I was thinking of at the time. I'm sure yours is still optimized better than what I would have come up with, though. I'd also guess that yours is one of the fastest implementations as well (short of Saturn/ARM code, of course).

A philosophical side note:

Your final complete solution is almost the exact same size as the code block I had to use just to reformat the string into a list of individual characters. While there may have been a shorter way to reformat the string, I think it points out a concept that I run across every time I try to "shoehorn" list processing into a solution. Namely, if the data doesn't start out as a list in the beginning, getting it into that format may not be worth the effort. While it's nice to be able to apply functions and processes to an entire block of data all at once, I still find the resulting code very difficult to read and maintain. It's probably just my lack of experience with that methodology. But I actually find yours and Wes' programs to be more understandable than my own.

I'm still inclined to force myself to use list processing when I get the chance, just to get to know it better. But for now, it still seems like a very specialized feature that is best suited for special circumstances (and less applicable to general-purpose use). Inherent to the methodology is that the underlying iterations are repeated for each applied process, which brings some inefficiencies with it.