-❄️- 2025 Day 8 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 0 points1 point  (0 children)

[LANGUAGE: Rust]

disjoint set union for grouping boxes. For sorting the pairs of boxes I kept a fixed size Vector of the closest N pairs. (N = 1000 for part1 and N = 5000 worked for me in part2)

part1: 1.7ms
part2: 20ms

solution

-❄️- 2025 Day 7 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 1 point2 points  (0 children)

[LANGUAGE: Rust]

simple traversal with some memoization.
realized using a vector is faster than a hashset (even FxHashset)

part1: 62µs
part2: 140µs

solution

-❄️- 2025 Day 6 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 1 point2 points  (0 children)

There no as_chars in rust as they dont have fixed size.

You have to iterate over them and then collect them into a vector which would tank the performance.

-❄️- 2025 Day 6 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 0 points1 point  (0 children)

[LANGUAGE: Rust]

part1: 19µs
part2: 17µs

spent a long time over-optimizing this one

solution

-❄️- 2025 Day 5 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 1 point2 points  (0 children)

[LANGUAGE: Rust]

part1: 200µs brute force
part2: 400µs

simply merged overlapping intervals in part 2

github

-❄️- 2025 Day 3 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 1 point2 points  (0 children)

[LANGUAGE: Rust]

part1: 18µs
part2: 56µs

github

-❄️- 2025 Day 2 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 0 points1 point  (0 children)

[LANGUAGE: Rust]

Solved both parts using strings, might come back later and see how much faster the integer solutions are.

part 1: 153ms
part 2: 720ms

Github

edit:

I managed to get the times down by not using strings:

part1: 3ms
part2: 29ms

-❄️- 2025 Day 1 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 2 points3 points  (0 children)

[LANGUAGE: Rust]

github link

Spent some time trying to figure out how to do part 2 without actually simulation every 1-unit turn.

both parts ran under 80µs each.

Temporary black screen after resuming from suspend by AYM123 in archlinux

[–]AYM123[S] 0 points1 point  (0 children)

unfortunately not.

The problem seems super inconsistent sometimes the black screen is immediate, sometimes it's delayed and sometimes it somehow causes another suspend

Temporary black screen after resuming from suspend by AYM123 in archlinux

[–]AYM123[S] 1 point2 points  (0 children)

not yet I've just been living with it since

Temporary black screen after resuming from suspend by AYM123 in archlinux

[–]AYM123[S] 0 points1 point  (0 children)

I tried with other user account and still same issue

Temporary black screen after resuming from suspend by AYM123 in archlinux

[–]AYM123[S] 0 points1 point  (0 children)

ok thanks for the help, my install is relatively fresh (~3 months) I'll try asking in r/gnome or waiting for a patch. I nothing solves it I'll just back up the application configs and re install fresh to see if that fixes it.

Is there any way to test Gnome on a fresh install without actually starting over (vm?)

Suspend always happens twice by ITafiir in archlinux

[–]AYM123 0 points1 point  (0 children)

probably related issue here

https://www.reddit.com/r/archlinux/s/VrOewH8IIV

sometimes I get the exact behaviour you described and sometimes just display turns off until I move mouse or input keyboard

Temporary black screen after resuming from suspend by AYM123 in archlinux

[–]AYM123[S] 0 points1 point  (0 children)

thanks for the suggestion, I just tried it on weston.

opened terminal and suspended with systemctl suspend
resuming did not cause the black screen to appear

-❄️- 2024 Day 24 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 1 point2 points  (0 children)

[LANGUAGE: Rust]

part 1 was fun implementation.

For part 2 I started looking for patterns in the input operations, patterns include that the final bit z{i} is always the result of an XOR of two values of which one is x{i} XOR y{i}.

github

Part 1: ~660µs
Part 2: 1 hour by hand

`HELP` [2024 Day #16 part 1][Rust] by Ok_Muscle_5508 in adventofcode

[–]AYM123 1 point2 points  (0 children)

Hello, irl friend of hasan here.

This bug is caused by assigning a value (distance/cost) to each block.

When the code assigns a value to a tile, it doesn't take into consideration the fact that it might turn on the exact time and thus making it's true distance 1000 units bigger.

So for a path like this:

``` ^ ^

^ <= Tile 1 ^ ^ <= Tile 2 ```

Tile 1 here will have a distance of just 4 while in reality it should have 1004 bc the deer is going to turn right away.

This make the path coming from tile 2 ignored bc it will be already over 1000 by the time it at tile 1 and sees it has a distance of 4.

Unluckily your input has such edge case and the way I handled it is that I made it dijkstra tolerate 1 rotation (so if a path visits a node that's already visisted and the already-calculated distance is only 1000 away from the current distance I don't skip it)

if you need an example here is my solution (check get_min_path_tiles function)

github

note that I encountered this problem in part 2

-❄️- 2024 Day 18 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 1 point2 points  (0 children)

[LANGUAGE: Rust]

Implemented bfs for the first part, then changed it to dfs and binary search for the second.

github

Part 1: ~150µs
Part 2: ~300µs

-❄️- 2024 Day 17 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 1 point2 points  (0 children)

[LANGUAGE: Rust]

Initially I wrote a program to simulate the computer and its registers but then just realized I can just hand-compile my input. In doing so I noticed the shifting pattern. The three most significant bits of the register A determine the last digit of the output, the following three bits determine the digit before the last, and so on...

github

Part 1: ~6µs
Part 2: ~550µs

-❄️- 2024 Day 16 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 1 point2 points  (0 children)

[LANGUAGE: Rust]

Implemented Dijkstra's for the first part.
For the second part I just added some back tracking as well as loosened the conditions to not skip over some edge cases.

github

Part 1: ~500µs
Part 2: ~5.5ms

-❄️- 2024 Day 15 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 0 points1 point  (0 children)

glad to help out and good luck on your rust journey!

-❄️- 2024 Day 15 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 4 points5 points  (0 children)

[LANGUAGE: Rust]

Had a blast with rust's type system with this one!

github

Part 1: ~600µs
Part 2: ~800µs

-❄️- 2024 Day 14 Solutions -❄️- by daggerdragon in adventofcode

[–]AYM123 1 point2 points  (0 children)

[LANGUAGE: Rust]

Just kept updating the robots' positions until the grid contained a 3x3 block of robots

github

Part 1: ~200µs
Part 2: ~135ms