ktims
3bfde9fd9b
day11: some cleanup, slight performance
2024-12-11 03:11:17 -08:00
ktims
2e239681ce
day11: performance
2024-12-11 00:55:47 -08:00
ktims
a7354b6ed7
day11: part 2 solution
2024-12-10 23:40:03 -08:00
ktims
462918b382
day11: part 1 solution
2024-12-10 21:55:00 -08:00
ktims
8af11a6092
day10: performance. slight gain from memoizing visited positions in p1.
2024-12-10 17:07:00 -08:00
ktims
d9d55b069f
day10: optimization
...
Part 2 doesn't actually require tracking state at all, it's enough to
just follow the rules and count every DFS that lands on a target square.
Part 1 optimized by only tracking which targets have been previously
visited, instead of all squares.
Both parts, pass position reference to recursive calls instead of by
value for tiny improvement.
2024-12-10 16:20:15 -08:00
ktims
0716dde8b1
day10: complete solution
2024-12-09 21:59:39 -08:00
ktims
206c1fca85
day9: optimize part 2
2024-12-09 00:23:40 -08:00
ktims
f7cf4f1e9f
day9: optimize part 1
2024-12-08 23:58:47 -08:00
ktims
b08c8fbd80
day9: use part 2 'inodes' table to speed up part 1
2024-12-08 23:51:51 -08:00
ktims
2bc751dd0d
day9: complete solution
...
previous commit should actually work for part 1 if you don't truncate
the input.
2024-12-08 23:34:15 -08:00
ktims
a6ea5b4155
day9: second rewrite, still failing
2024-12-08 22:57:20 -08:00
ktims
622877843e
day8: refactor and cleanup
2024-12-07 22:49:57 -08:00
ktims
47e40942e2
day8: complete solution
2024-12-07 21:43:56 -08:00
ktims
3e0bc0d5cc
day7: parallel solution, < 100ms
...
This is definitely a problem that calls for DFS, but I couldn't be
bothered.
2024-12-06 22:52:00 -08:00
ktims
868c3e56fc
day7: complete solution
2024-12-06 21:40:25 -08:00
ktims
fee37aebd0
day6: further performance improvement, ~55ms total runtime
...
We only need to run the guard forward from the step before the obstacle
we placed, instead of starting at the original starting position.
The code starts to look ugly...
2024-12-06 17:05:36 -08:00
ktims
b1918bbebf
day6: performance - only check obstacles on the original path
...
700ms -> 150ms
2024-12-06 10:59:43 -08:00
ktims
1cd535c2aa
chore: clippies
2024-12-06 10:52:31 -08:00
ktims
1dd3ce5862
day6: performance improvement
2024-12-06 10:40:28 -08:00
ktims
145d779e83
day6: complete solution + grid lib (used in solution)
2024-12-05 22:41:47 -08:00
ktims
49c37800a0
day5: complete solution
2024-12-04 22:41:33 -08:00
ktims
e2cd0fe9cc
day3: code format
2024-12-04 16:41:39 -08:00
ktims
6a619d756f
gitignore
2024-12-04 16:41:16 -08:00
ktims
dc67b38420
day3: disable unicode matching, don't recompile RE for every iteration
2024-12-04 16:41:00 -08:00
ktims
e5faee3470
day4: do a lot fewer allocations, performance improvement x10
2024-12-03 22:09:13 -08:00
ktims
a81904f2eb
day4: complete solution
2024-12-03 22:02:49 -08:00
ktims
ec55b07c61
boilerplate: fix it
2024-12-02 21:22:05 -08:00
ktims
7a7fb4d02a
day3: full solution
2024-12-02 21:18:37 -08:00
ktims
b24593a469
day2: performance and adopt new duration print
2024-12-01 23:02:00 -08:00
ktims
ec2651c3e4
boilerplate: improve duration printing
2024-12-01 21:32:17 -08:00
ktims
33c0c876c3
day2: full solution
2024-12-01 21:31:29 -08:00
ktims
968d795720
day 1: cleanup and refactor
...
* I misunderstood the problem and thought we were asked for the distance
between the numbers' positions, not their values. Removed remnants of
that.
* Move to struct-oriented solution
* Fix clippys and unnecessary code
2024-11-30 22:03:19 -08:00
ktims
8cab780ff3
day 1: problem 2 solution
2024-11-30 21:46:10 -08:00
ktims
892d59f21b
day 1: problem 1 solution
2024-11-30 21:38:31 -08:00
ktims
76cacf4704
gitignore
2024-11-30 21:37:02 -08:00
ktims
fd24918c7a
2024 AoC is here!
2024-11-30 21:36:05 -08:00
ktims
