Only one day left!!!
Pretty pleased that I worked out the right techniques and implemented them without too much trouble.
For Part 1, depth-first-search. I kept track of visited nodes, just in case there were any loops. I’m not sure that there are, but it can’t hurt to be safe. I worried that I’d need to cache the number of paths from a node to out for Part 1, but I didn’t.
For Part 2, it’s still depth-first-search, but it didn’t surprise me that just re-applying the solution to Part 1 doesn’t work. You’ll have to be a little more clever here. Here’s what I did:
- Break it up into parts:
svrtofft,svrtodac,ffttodac,dactofft,ffttoout,dactoout. - Only one of
ffttodacordactofftshould actually have any routes. Otherwise, the math below is wrong. Indeed, lots of people on Reddit confirm that this is a property of their input. - Suppose you have
ffttodac, as I did. Then you can count A paths fromsvrtofft, B paths fromffttodac, and C paths fromdactoout. - By the counting principle, the answer is A * B * C.
- This will probably be larger than
2**32, so break out yourrangedefinition, orBig_Big_Integer, or whatever. - One more trick: you need to cache the number of paths from each node to the goal. – Well, maybe not all three. I was able to find
dactoouton my own, but choked onsvrtofft, even though the result isn’t all that big; there must be a lot of spurious routes.