The puzzles are getting harder. Luckily, it turned out for me that for day 13 the paddle did not need to be moved for the ball to hit all the blocks. The ball bounces of the bottom in any case. It may be worth just watching the output and iterating for some time to see if all blocks get hit.
(I probably should start to use svg or webgl for graphics.)
Haha, that’s very clever! The game in fact does terminate and spit out a zero score when the ball hits the bottom, but since your code automatically restarts the program with its last state whenever it terminates, you end up beating the game with zero effort!
Yeah, I only wanted to get a first sense of what’s happening by just keep going and so did not check for stop conditions, like 99 or a request for input. Also, it was easy to just make a yielding generator to keep watching the output visually. The plan was to parse the output for blocks (which is already happening for part 1) after each iteration which would not require the yielding and presumably would be much faster, and if this would not work to start controlling the paddle to align with x position of the ball. But just waiting and watching was more fun.
I get the sense there is some randomness in the ball bouncing which may be enough in many cases to cover all the blocks. No, Intcode could not do that.
haha, I see you found my solution to day 13 already. my generator syntax for input and output is finally paying off dividends. it was pretty natural to write out “move the paddle to under the ball” for my input and fast forward it to the end to finish part 2 immediately after part 1.
I’m still stuck on day 12 (n-body problem) part 2. I have a line of reasoning on it in my notebook that hasn’t panned out yet. hopefully I’m on the right track…
Yeah, nice notebook. I tried your puzzle as well, and it also does not take the ball too long to hit all the blocks without paddle control. BTW, the emojis show up as different ones on my system than shown in the notebook preview, including an invisible ball.
I think you are on the right track with day 12. I do not want to spoil the discovery but you are welcome to look at:
This worked for me although I think strictly one would have to check if repeats for all dimensions start on the same universe which I do not think I am doing. Also, even in just single dimensions it can take a lot of universes to loop back (more than 200k , for me). The final combinatorial step requires factoring.
I also thought first that the total energy may be a useful hash but it was more a red herring than helpful. So I ended up just using concatenated positions and velocities.
Yeah I realized any time velocity hits 0 you’ll get a collision, but it’s a good visual check.
Thanks for the pointers! I’m debating if I should look or not… 
oh, I had missed the 'not in ‘not spoil’.
I think you already identified the key idea which is treating each dimension independently to divide and conquer. It took me some time to realize that this is possible since then the repeat time can be computed as the smallest number which is a multiple of the repeat times in each dimension. I determine this as the product of the smallest set of prime factors which contains the factors for each dimension.
231614, 116328, 102356
Yup! I just found an npm library to do my math for me 
. “least common multiple” is the math concept, which I wasn’t fully sure was the correct concept to apply here, but makes sense that it is.
To me, I really like the leverage that Observable gave me to explore the x, y, z periodicity angle visually and giving me very quick feedback that I was probably on the right track. I don’t see how I personally would’ve verified that easily if I were stuck in a terminal or looking at pages of numbers.