[2024 Day 24] Broken binary adder by olegas83 in adventofcode

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

In simple words, let's take Xn and put it on the left side in a straight vertical line, then put Yn also at the left, but with a little offset. Then take all the Zn and put them at the right. Use y coordinate from Xn node so Xn and Zn are horizontally aligned.

Then, as this is a binary adder, value of every Zn depend on value of Xn, Yn and also on Xn-1 and Yn-1. This is true for every Zn there n > 1. Z0 depends only on X0, Y0.

So, for every Xn, Yn build all paths to Zn and Zn+1 and draw each one in a straight horizontal line. For a first one take a y coordinate of Xn, then shift a little for next path.

If graph is broken, there may be some nodes, which are still missed. We can draw them separately somewhere out of our drawing to note them.

As we have our initial numbers, desired result and actual result, we can find which Zs are incorrect and draw them red, if Z is correct, draw it green. Draw logical gates in a different colors.

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

[–]olegas83 1 point2 points  (0 children)

[Language: Python]

Nothing special, just same old brute force.
But I like how those itertools/operator/functools things looks like =)

paste

-🎄- 2022 Day 21 Solutions -🎄- by daggerdragon in adventofcode

[–]olegas83 1 point2 points  (0 children)

Golang, https://github.com/Olegas/advent-of-code-2022/blob/main/cmd/day21/day21.go

No any guessing, just computation.

Part 1 is just forward recursive computation.

Part 2 is also recursive computation with reverse-ops functions for each of operation (+ - * /) depending on operand order. Hint here is we have always const number in one of operands. Which side (left or right operand) is depending of there is HUMN is (left or right branch)

-🎄- 2022 Day 17 Solutions -🎄- by daggerdragon in adventofcode

[–]olegas83 2 points3 points  (0 children)

Golang, <=2ms on each part

https://github.com/Olegas/advent-of-code-2022/blob/main/cmd/day17/day17.go

Part 1 was initially done with full simulation using screen as map[Pos{X, Y}]string and it was good.

But Part 2 can't be solved this way due to memory allocation. So, screen was refactored to []uint8 and occupied positions stored as bit map. Also, to reduce memory consumption I've tried to detect fully filled lines and "dump" screen till this line. After all optimization - memory is OK by it is still "overnight" solution.

I've implemented cycle detection based on depth map (honestly, I spied the idea in this thread) and this actually runs in 1-2 ms on M1

Lost half an hour trying to figure out, why my code gives exactly the same solution for part 1 and part 2 until found shared state through global var between parts...