@@ -136,4 +136,21 @@ Finally, the data structures I am using are extremely simple:
...
00000000 -- binary representation of digit #9
... (10 bytes total)
```
\ No newline at end of file
```
# Day 9
## Part A
The trick here is the boundary behavior -- trying to read off the edge of the board should be treated exactly the same as reading a '9'.
2-D indexing is a huge pain in Forth, so I wanted a simpler way to track the board edges. Here's what I sound up doing.
-**For the left and right edges** - When reading input, pad each line with a leading '9'. The empty line at the end of input also counts as a "line" so the effect of this logic is to '9'-delimit the input lines and the first and last character of the board will both wind up as '9's too.
-**For the top and bottom edges** - Clamp out-of-range addresses to first or last character of board, which are now guaranteed to be 9's.
The result: x,y coordinates are now largely irrelevant and we can just traverse every square without worrying about boundary conditions.
The check of each square against its neighbors is very simple and there is probably a more elegant way of writing it, especially in Part B where significant code duplication creeps in.
## Part B
Same as above, but when I find a low point I kick off a recursive flood-fill there and track how many squares I filled (see `basinsize`). Once the basin size is known, I store it in the minimum index of a 3-long ascended-sorted array, and re-sort that array to ensure the least of these top-3 values winds up in the minimum index again ripe for replacement. At the end of traversal I multiply together the top three values to get the answer.