AoC 2020 - Day 12: Rain Risk
This was instructive!
I always have issues with rotations. I know the basics, I know the general
ideas, but when I need to start doing it, I feel like trigonometry was too far
in the past, and I am not able to do anything.
So I usually navigate my way through, trying to reinvent the math.
This time, I wanted to sit down, and find a better answer.
First refactoring, was to use a matrix for the rotation. A point is a vector,
and can be rotated my multiplying with a rotation matrix. In our case, the
rotation matrices are very simple, as we only rotate by 90 degrees:
[[0, -1][1, 0]] and so on.
This first approach was very nice, and reduced the bunch of ifs quite a lot;
still, the code, using tuples for the coordinates was too complex.
So I realized that a point is a complex number; and then, in a complex number,
we can easily extract the phi, and make sums like champs thanks to cmath.
There is some additional issue now, related to integers: AoC uses integers only,
but complex are float, so there is now the need for rounding, and the risk of
floating point errors.
Anyhow, the new approach was even simpler, but it still was wasting too much
branches for the translations over x and y.
The last approach (almost) unifies all movements across all axis (x, y, rotate),
with a much simpler dispatching.
It’s not perfect yet, but I think it’s enough for the moment.
Learning items:
- Linear algebra – this is something I need to study again
complexandcmathin python – they are really nice!