Day 11 is the day I give up PostScript and switch to Rust.
Yup. The actual problem solving part would have been fine, but string parsing when all you can do is search for a substring is a Pain.
So I did it in Rust and then I went back and did in PostScript anyway.
For day 11 part 1 I’ve finally gone full OO. I seem to be having some issues running the necessary number of iterations for part 2. Time for a cup of tea and a think about optimisation.
Edit: The prime divisors were a bit of a giveaway so I threw the modulo operator at the problem and it seemed to work. As a former mathematician I feel like I should understand why that worked a bit more than I do.
Even division means w mod t == 0.
Define m which is a multiple of t.
(w mod m) mod t == w mod t.
My solution builds an m which is the product of all t.
Question for part 2 of Day 11:
I solved part 1 with a nice Monkey object that used Integer for the calculations of the item anxiety levels.
With part 2 I am getting overflow issues. Long also isn’t enough.
I tried BigInteger but it is too slow.
What am I supposed to be doing?
Day 11 part 2 needs you to replace the “divide by three” from part 1 with some other mathematical trick to avoid the numbers getting too large. HTH.
extending the above
while still ensuring they pass the divisibility tests in the same way that the larger numbers would.
Thanks
I think this is too mathsy for tonight.
I might ask my partner. He’s better with numbers than I am (after failing way more math exams at uni than I did). I just write code. He watches math youtubers for fun. And he owes me: sieve stopped working the moment he began using the new server…
I have too many guesses made and don’t remember which ones I tried.
We spent way too long on this puzzle.
My partner suggested the eventual solution using the primes as suggested here and I tried this but had the wrong number of rounds (by factor 10). This was my last attempt. I noticed the rounds were off and one more try… was it. I now get it… well, my partner is happy he suggested the solution.
Now I can start work. And I am not looking at day #12 until everything I have to do is done.
Day 12
Part 1 “Exhaustive DFS won’t work, let’s try Dijkstra.”
Part 2 “Actually Dijkstra was the right choice, because now I just reverse it.”
After day 9 I made sure to make this visually debuggable and it was oh-so satisfying to watch the solution unfold.
As I was coding this I was thinking of it as a “flood-fill” though looking at an animation of Dijkstra’s algorithm it does look very similar.
I managed to capture the output:
There must be a better way of capturing PowerShell output than recording it via the Windows Game Bar/AMD software and passing the video through Imgur twice to crop it and convert to a gif. It’s also not nearly as smooth as a gif.
I almost implemented the algorithm for Day 12 on my first attempt (which took me a while). But once again I didn’t fully read the problem description, I am so used to just glancing over text and quickly scanning for information that in a case like this I tend to overlook crucial pieces of the puzzle.
So because I had missed the climibing equipment I thought I was wrong, asked the internet and now I am confused
Once again it is time to take an overnight break and hope for the best in the morning.
There is definitely a key piece of the description that I almost missed and had to read several times to make sure I understood it.
And thanks for the tip with visualization. I thought I’d fix mine and run it again and it showed me that I couldn’t get the actual input running because I had assumed that the staring position would be at 0,0 when it was not which was the bug preventing me from solving part 1.
I must admit that I verified my half implemented algorithm against the internet here.
I finished Day 12 last night even as I posted I wasn’t going to. … part 2 was easy for once. I just had to implement a set of possible targets and a new heuristic for the algorithm and adjust the “isMoveLegal” method to get this done in 5 minutes.
Got started on Day 13 … the framework is there. I just need to figure out (once again) how to parse the input and then implement the actual left-right comparison for the packets.. I have begun using the test input they provide every single time now. There are some tricksy inputs here… like the empty packet with an empty list inside
In theory this will be the final line for today’s puzzle:
packets.stream().filter( Packet::isOrdered ).map(Packet::getPosition).reduce( 0, Integer::sum );
I have candles within arm’s reach of my home desk.
“If you don’t reap your children, they end up as zombies.”
Day 13 was definitely a “PostScript as exercise weights” day.
Part 1: I pretty much have to use token
for parsing, which (I later realise) means wrapping the string in {
}
before feeding it in. (Also split on comma and rejoin on space, but I’ve already written library functions for that.) Not a huge recursion fan but it seems pretty clearly the right way to do it here.
Part 2: oh right. PostScript doesn’t have a native sort. I wrote a quicksort a few months back, but it relies on being able to use the native comparators on array elements rather than being passed a function. So I bodge that in, and then dictstack overflows (too much recursion), so I build a comparator table (do every possible comparison and then use that as a sort comparator); then several rounds of bugfixing. Actually it was probably a different error but I leave in the comparator table anyway. Since for simplicity I end up sorting the packet index numbers rather than the packets as such, I just have to look for the indices of the target packets in the sorted output list.
Just had a look at Day 13. Maybe later.