this post was submitted on 06 Dec 2024
26 points (96.4% liked)
Advent Of Code
979 readers
29 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
Rust
This one was the first real think for this year, but I ended up brute forcing it, placing a β#β in every position and checking. part 2 runs in about ~~380ms~~ 78ms (after reducing the amount β#β-placements to only where the guard walks) on my 2011 core i-7, so Iβm happy, even though it feels like I could have been smarter.
Part 1 Part 2
I am doing the same principle brute force but it takes ~7 seconds oO
Is using a
HashSet<(Pos, Dir)>for the loop detection so expensive? My CPU shouldn't be THAT bad..Part one around 7ms.
Also curious that i have not seen someone mention a more efficient approach, there gotta be one?
I draw
^>v<characters on the grid while walking, so then it's a direct array lookup (instead of a hashtable). The representation could be better though, some kind of bitmask would beat checking against a bunch of characters.I dont change the map, i just record the steps in the hashtable. But maybe drawing on the map is indeed shaving some time off, thanks for the input :)
It probably wonβt matter a whole deal but array indexing involves no comparisons or searches. And I found it convenient too!
Iβd like to see your solution in total. Iβm not too familiar with the nuts and bolts, but hash set is quite a bit more expensive than a simple vector, thereβs a bunch of overhead incurred when executing the hashing and placing of the data, and when repeating a few thousand times it sure adds up. My part one hovers around 600 microseconds.
I set it up a bit like a game, https://pastebin.com/FGA6E7fA
Ohhh, that says my part 1 is slow already, i was sure my approach for 2 was the problem. Good to know!
I created rows and cols vecs that keep places of blocks. When moving, I binary search the row or col, find the block that stops me. So moving whole sections at once. Otherwise used HashSet of pos and dir like you. Also in part 2, place the new block only on the path I take in part1. Part 2 is 26ms.
code
The binary search sounds smart, would reduce the pathing quite a bit i guess :)
Part 2 i approached quite the same i think, was only a couple lines of code additionally. But running 5ms 5000 times is also gonna take a while..
Alright, I completely forgot about
--releasebecause i normally use just to run my stuff. That brings part 2 down to around 400ms, i am okay with that for now :D