:christmas_tree: Day 23 : Solutions Thread
# advent-of-code
a
🎄 Day 23 : Solutions Thread
Brute force using mutable lists will work for Part 1 but will never scale for Part 2. Opted to use an array rather than implementing ListedList-style nodes, each array[n] points to the element following n in the sequence. Moving a block is then simply a matter of changing three elements in the array.
j
it's all about the data structures your language of choice allows you to use... and when it does not provide one, you wrote that yourself. Lo and behold: Fully functional linked list node in Kotlin:
Copy code
class Cup(val id: Int) {
    lateinit var next: Cup
}
🧌
and whole solution (sans init block, collapsed for readability):
n
I looked at the linked list in Java
is it just me or is that class missing all the stuff that makes a linked list worth using
t
@Jakub Gwóźdź - I had the same idea as you, but my node class (also called
Cup
!) can do a
toString()
until it loops around and has a function to gather the next
n
cups into a list (which I use twice). Most everything else is in my
Cups
class, which looks a bit different. It takes ~5s on my machine to do P2, which I guess is fine.
j
Also - got 1.20s on surefire (JVM) and 1.36s on jsBrowserTest on github actions worker 🙂
t
Wow that is quick. I'm probably not doing the "next 3" part as efficiently as you are.
e
<300ms on JVM for me. thanks to primitive arrays and no abstraction
t
Wow, nice!
Probably could make that faster if I didn't implement the next 3 the way I did, but meh.
l
I used the
operator fun componentX
to extract the few next ones without building intermediate lists, but I can't chain calls with that approach
n
Too lazy to do the -1'ing for a list so i just used a map 🙂
generate sequence is extremely slick here
b
I have a solution that works for 10 but not 100…
nevermind
I think I have a fast and super simple solution (lets see in part2)
hah
ok nevermind that as well 😄
1.3 seconds for part 2 on the bare JVM
1.2 with εGC and Xmx8g