this post was submitted on 20 Dec 2024
12 points (92.9% liked)
Advent Of Code
980 readers
26 users here now
An unofficial home for the advent of code community on programming.dev!
Advent of Code is an annual Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like.
AoC 2024
Solution Threads
M | T | W | T | F | S | S |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 |
Rules/Guidelines
- Follow the programming.dev instance rules
- Keep all content related to advent of code in some way
- If what youre posting relates to a day, put in brackets the year and then day number in front of the post title (e.g. [2024 Day 10])
- When an event is running, keep solutions in the solution megathread to avoid the community getting spammed with posts
Relevant Communities
Relevant Links
Credits
Icon base by Lorc under CC BY 3.0 with modifications to add a gradient
console.log('Hello World')
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Haskell
First parse and floodfill from start, each position then holds the distance from the start
For part 1, I check all neighbor tiles of neighbor tiles that are walls and calculate the distance that would've been in-between.
In part 2 I check all tiles within a manhattan distance
<= 20
and calculate the distance in-between on the path. Then filter out all cheats<100
and countTakes 1.4s sadly, I believe there is still potential for optimization.
Edit: coding style
Hey - I've a question about this. Why is it correct? (Or is it?)
If you have two maps for positions in the maze that give (distance to end) and (distance from start), then you can select for points p1, p2 such that
d(p1, p2) + distance-to-end(p1) + distance-to-start(p2) <= best - 100
however, your version seems to assume that distance-to-end(p) = best - distance-to-start(p) - surely this isn't always the case?
There is exactly one path without cheating, so yes, the distance to one end is always the total distance minus the distance to the other end.
Gotcha, thanks. I just re-read the problem statement and looked at the input and my input has the strongest possible version of that constraint: the path is unbranching and has start and end at the extremes. Thank-you!
I missed that line too:
So I also did my pathfinding for every variation in the first part, but realised something must be wrong with my approach when I saw part 2.
(I ask because everyone's solution seems to make the same assumption - that is, that you're finding a shortcut onto the same path, as opposed to onto a different path.)
Some others have answered already, but yes, there was a well-hidden line in the problem description about the map having only a single path from start to end..