@ -9,39 +9,96 @@ In essence, this a two-dimensional version of the elevator problem in @secref["d
@chunk[<day3>
@chunk[<day3>
<setup>
<setup>
<q1>
<q1-complex>
<q2>
<test>]
<test>]
@section{How many grid cells are visited?}
@section{How many grid cells are visited?}
In the elevator problem, we modeled the parentheses that represented up and down as @racket[1] and @racket[-1]. We'll proceed the same way here, but we'll assign Cartesian coordinates to each possible move — @racket['(0 1)] for north, @racket['(-1 0)] for west, and so on.
In the elevator problem, we modeled the parentheses that represented up and down as @racket[1] and @racket[-1]. We'll proceed the same way here, but we'll assign Cartesian coordinates to each possible move — @racket['(0 1)] for north, @racket['(-1 0)] for west, and so on.
For dual-valued data, whether to use @seclink["pairs" #:doc '(lib "scribblings/guide/guide.scrbl")]{pairs or lists} is largely a stylistic choice. How do you plan to process the data? In this case, the way we create the path is by adding the x and y coordinates of the current cell and the new move. So it ends up being convenient to model these cells as lists rather than pairs, so we can add them with a simple @racket[(map + move cell)].
For dual-valued data, whether to use @seclink["pairs" #:doc '(lib "scribblings/guide/guide.scrbl")]{pairs or lists} is largely a stylistic choice. Ask: what will you do with the data next? That will often suggest the most natural representation. In this case, the way we create each cell in the path is by adding the x and y coordinates of the current cell to the next move. So it ends up being convenient to model these cells as lists rather than pairs, so we can add them with a simple @racket[(map + current-cell next-move)]. (Recall that when you use @racket[map] with multiple lists, it pulls one element from each list in parallel.)
Once the whole cell path is computed, the answer is found by removing duplicate cells and counting how many remain.
Once the whole cell path is computed, the answer is found by removing duplicate cells and counting how many remain.
@chunk[<setup>
@chunk[<setup>
(require racket rackunit)
(require racket rackunit)
]
@chunk[<q1>
(define (string->cells str)
(define (string->cells str)
(define start '(0 0))
(define start '(0 0))
(match-define (list east north west south) '((1 0) (0 1) (-1 0) (0 -1)))
Rather than use Cartesian coordinates, we could rely on Racket's built-in support for complex numbers to trace the path in the complex plane. Complex numbers have a real and an imaginary part— e.g, @racket[3+4i] —and thus, represent points in a plane just as well as Cartesian coordinates. The advantage is that complex numbers are atomic values, not lists. We can add them normally, without resort to @racket[map]. (It's not essential for this problem, but math jocks might remember that complex numbers can be rotated 90 degrees by multiplying by @racket[+i].)
Again, the problem has nothing to do with complex numbers inherently. Like pairs and lists, they're just another option for encoding dual-valued data.
@section{How many grid cells are visited if the path is split?}
By ``split'', the puzzle envisions two people starting at the origin, with one following the odd-numbered moves, and the other following the even-numbered moves. So there are two paths instead of one. The question remains the same: how many cells are visited by one path or the other?
The solution works the same as before — the only new task is to split the input into two strings, and then send them through our existing @racket[string->cells] function.
