znProjects Blog

Software is beautiful again!

If you just want to jump into the code, the code for Day 1 is on GitHub.

The problem

Part 2 adds a small twist to the problem. Instead of just finding an end-point, you have to find the first block that you visit twice.

This is not as simple as checking against the end points of each move. Rather each intermediate block that you visit is a candidate for being the final answer.

Note about the problem

If you have not finished Day 1, Part 1 yet, the AOC website will not show you the Part 2 text. If you need to do Day 1, Part 1, please see my post on that subject.

Do the lines intersect?

There are a few ways to solve this problem.

Keep a list of all Points (as sets of 2D Cartesian coordinates). Then, every time you move, check if you are passing over an already visited block.

Store the lines that represent the moves you have made so far, in order. Then, when making a new move, check whether the new 'line of movement' intersects with any of the previous lines. If there is an intersection, find the point of intersection.

I first thought of implementing solution #1, but found solution #2 more interesting because I do not currently know how to calculate whether two lines intersect or what that intersection point is.

So, I started out by reading about lines and intersections. I started with various "game" / graphical algorithms because I assumed that this is a problem that game developers encounter often. Like most people (I imagine), I first ended up at Wikipedia. This is a great article that is heavy on theory and light on implementation details. A lot of the information, not only on Wikipedia but on various sites, involves knowing the equation of the line. I had the end-points, but did not readily have the slope-intercept form of the lines. After quite a bit of searching, I ended up on Martin Thoma's article, How to check if two line segments intersect.

I highly recommend reading this article if you haven't seen it before. He has an excellent explanation of line-line intersection. I actually implemented most of Martin's code (in F#) and it is quite solid. But then, I started reading Gregory Stein's comment on the same page regarding cross products of vectors. I really liked Gregory's idea, mainly due to the succinctness of the code. So, I also translated Gregory's code to F#. In the end, I went with Gregory's algorithm.

I can safely confirm that this code does work. This function has signature Point * Point -> Point * Point -> bool. Recall from Day 1 that a Point and a Location are defined as:

type Point = { x : int y : int}

type Location = { dir : Direction pt : Point}

Initially, my x-y coordinates were saved directly in the Location record. However, once I decided on a solution for Part 2, I actually went back, changed the data types, and refactored the Part 1 code so that it would continue working.

Where do they intersect?

Once I knew that two lines intersect, the next job was to find the intersection point. I looked at a number of sites and ended up adapting the code from Intersection of lines in 2D.

This function's signature is Point * Point -> Point * Point -> Point. It takes 2 lines, each represented as a pair of Points, and returns the intersection Point.

Putting it all together

I wanted to re-use, as much as possible, the code I had already written for Day 1, Part 1. Specifically, I wanted to re-use the move mechanic. To achieve this goal, I wrote my final function per the following spec:

Parse the instructions

Perform the moves while preserving all intermediate Locations.

Extract the Points from the Locations, since the Direction isn't important once the moves are complete.

Create conceptual lines by creating pairs of individual Points.

Iterate over the list of Lines (which are really just Point tuples) to find an intersection, but with a built-in short-circuit. Once we find an intersection point, we don't want to update it again in the future.

Finally, pull out the intersection point (if any) and calculate the distance from the startPt (which is at (0,0)).

The things I love about F# is that I was able to translate this spec almost line-for-line into code. I called this function dupFinder because I figured that we are trying to find the first Point that is a duplicate in the route we have traveled thus far:

And this is it. I invoked the dupFinder function with the input string (same string as Part 1) and got the correct answer.

The answer you get with this code is 141, which is, in fact, correct.

If you want to see the code for Day 1 (both parts), please head over to GitHub.

But what about testing?

As you may have noticed, I barely have any testing in my code. In the beginning, I debugged by code using a combination of code reading (gotta love static typing!) and the tee function to print debugging information during execution.

This handy little function allows you to inject arbitrary commands (such as printfn or logger.Log) into the middle of a pipe chain without disturbing the rest of the code. It takes a function and an argument, executes the function, ignores the result (if any), and passes the original argument forward. Obviously, this wouldn't work so well if the function somehow mutated the argument. Luckily, F# makes it at least a little annoying to write functions that mutate values, and I almost always only use tee to do mid-pipe log entries / debug output.