|R Advent: Days 11-15
||[Mar. 9th, 2016|11:28 pm]
Work is nothing but meetings and proposal writing this week. Ugh. |
Day 11 [LOC: 26/3]
I know there are some languages where I could just say "pw++" to increment the password, so I was a little disappointed I had to spend 9 lines of code on that inc() function. The very idiomatically R thing about this solution was realizing that I could check password validity by constructing the full lists of double letters and 3-letter runs, splitting the password into lists of doubles and triples, and using %in% to count how many of the former occur in the latter.
Day 12 [LOC: 2/23]
Ugh, JSON. JSON does not play nicely with R. There are a couple packages for parsing JSON, but they're designed to work with something that has a sensical structure that you want to pull data out of, not the arbitrary mishmash of nested arrays that you use for a puzzle, and they don't preserve the array/object distinction (which isn't a thing in R) in a way that lets you solve part 2. Fortunately, you can solve both parts without actually parsing the JSON!
The first part is trivial if you just treat it as a great big string that you're searching for numbers, making this one of the few puzzles where Part 1 is shorter than Part 2. I got stuck on the second part for a while until I ran across a hint in the reddit forums for the challenge that pointed out the key to solving it without parsing the JSON: you want to remove all the elements with a "red" tag, and if you look for closing curly braces, you can just check everything back to the matching open brace. It's a little bit of a cheat not to have figured that out on my own, but JSON is so far outside R's wheelhouse that I don't feel bad about it.
Day 13 [LOC: 13/6]
This is the first one where I pre-processed the input outside of R to clean it up. (I used search-and-replace in emacs to transform "Alice would gain 2 happiness units by sitting next to Bob." to "Alice +2 Bob"). I could have done that with some global search-and-replace in R, but I was trying to conserve lines of code at that point and didn't feel like writing a bunch of gsub() expressions.
I was glad that R has a permutations() function in its core, because it would be tedious to write your own. I'm also glad that the problem was small enough that the full set would fit in memory all at once and I didn't have to iterate through the permutations one at a time.
Day 14 [LOC: 8/12]
Not a lot to say about this one. It was pretty straightforward. I guess the last line of Part 2 is kind of interesting, because it's that data origami thing where you can do a fairly sophisticated calculation in almost no code if you have the right structure set up. Having constructed a speed-vs-time array, you convert it to position-vs-time by taking the cumulative sum along time. Then you apply which.max and use it as an index into the reindeer array to get a vector of names of which reindeer is in the lead at each timestep. And then table() tallies those names up, so max() tells you which one was in the lead most often. What's cool is that actually remains fairly comprehensible even when you've nested all those functions into a single line of code...
Day 15 [LOC: 18/3]
The compositions() function from the partitions package lets you avoid a HUGE amount of effort and inelegant code in this one. (Once you figure out that "compositions" is the name of the thing you want to do, anyway...)
Literally half my code here is dealing with the suboptimal input format. If the input were structured better, you could tersify the code a little and do the whole thing, both parts, in about 8 lines. 8 lines! This is why I like R.