HHC 2017 RPL Programming contest information and results thread

[3298]

Oookay, I posted my code, now I have the official numbers to test on.
UserRPL score: 26748.8744054
SysRPL score: 21888.9128444
What they returned:
- Number 1: 3+9+230+129375, like all Nashville contestants.
- Number 2: 3+12+169+29040+3239579892, result (3) in Gene's list.
- Number 3: 3+13+253+218314, the point where my exit condition trickery avoided a big denominator compared to both Nashville results.
- Number 4: 2+3+51+17000, result (2).
- Number 5: 2, no failure.
It was obvious that the SysRPL version would be better than the UserRPL one, because it produces the exact same results in a smaller program. Though I don't know the size of the Nashville submissions, I doubt they were small enough to make up for what I won at number 3 by dropping their last denominator.

But I'll look further and test whether the "evil judge protections" () were really needed...
- The version I presented used an exit condition of <=1.E10. If I used <1.E9 instead to save 2.5 bytes (applies to both languages), I would have lost some points on number 2 by hitting result (2) instead (assuming 20940 is a typo for 29040). It substitutes 323.9579892*bytes (25106.744163 for UserRPL, 20247.374325 for SysRPL) in score for 30868.1999931 points (according to my 50G) for the increased error. That hurts, so this has to stay.
- The other protection was designed to handle tiny inputs below the exit threshold by not entering the loop at all. There were no inputs like that, so this can go, saving 2.5 bytes on the UserRPL version and 5 bytes on the SysRPL version by exchanging the WHILE loop for an UNTIL loop, which removes the :: ; (= 5 bytes) around the part of the loop that actually adds the denominators to the list. Unfortunately the UserRPL has a SWAP at the start of the exit condition checking code that has to be run on entry, so that needs to be added between the empty list and the start of the loop, so the savings are only 2.5 bytes in that case. The scores would be 25938.8808119 and 19458.9320639.

I also tried Claudio's fancy optimizing program on the stock firmware. It's definitely slow, but hey, speed is not rated. It also needed a small fix to be accepted by the compiler (remove the tick marks from FOR 'A'). These are the results:
- Number 1: 4+9+21+55+88+186+399+687+1592+1793+3249802
- Number 2: 4+10+25+61+128+231+840+722+1229+1441+6055831
- Number 3: 5+9+19+38+81+177+327+681+1161+1296+4549514
- Number 4: 2+5+12+27+58+341+161+316+655+2871+9574+3583+1218+2700367
- Number 5: fails on ΣLIST. It's an easy fix, though - just write 0. + ΣLIST, then it works and returns 2.
The score is impressive: 1300.2357774 for the original version (603 bytes on stock firmware), or 1308.5296064 for the number-5-fixed version (the errors count for 300 in both cases). I think we have a winner - though there's some optimization potential left in the program size. For instance, reducing the variable names down to one character would save quite a few bytes here and there, since the UserRPL compiler does no NULLLAM conversion.

(09-18-2017 11:21 PM)Paul Dale Wrote:  At 100 points maximum for each error

Wouldn't that be 100 * 1.E12 due to the scaling applied to the returned error? That clearly makes the simple no-denominators program the worst possible one.