Yup, that's true

28:07 And my comment goes to waste, lol

Yes, I mainly use the stars to judge the difficulty of part 2, because that's the part I tend to be interested in. At least, in earlier years I usually felt like part 1 was a light 'warm up' for the real thing, but admittedly this year that doesn't tend to be the case, part 2 feels a lot less predictable.

Haha, nice.

Oh, nice

What was your solution?

​@@hextree My input.txt is similar. It divides A by 8, outputs B % 8 and jumps from the end to 0. B and C are reset every iteration. The length is also 16. I have been experimenting in python's command line for a few hours before I noticed it. I found the answer in a very complicated manual way. Then it hit me. # The function execute(a,b,c,program) is defined in part 1 # This is the entire part 2 a = [0] for i in reversed(range(len(program))): a = [j*8+k for j in a for k in range(8) if execute(j*8+k,0,0,program) == program[i:]] return min(a) It calculates the answer 3 bits per iteration. The trick is you can take first N digits of the answer, run the program and it should output the last N numbers of the program. Then you shift it 3 bits to the left and add the next octal digit.

Nice, this is a lot more compact. And easier to understand now that I've had 1 day to clear my head of nonsense haha. Definitely I was a bit too hung up on using binary digits, which wasn't necessary, but I guess it reflected how I was visualising the number.

Oof, yes I usually copy and paste these days but I really should save file to be safe.

Hmm. Interesting thought, but I'm not convinced people use the term that way. For instance in casual conversation if I had a shop 1 mile North of my house, and a park 2 miles South of my house, I would comfortably say "the park is twice as far away as the shop". It seems valid to me.

Yeah, I've used dequeue for a couple of problems for FIFO stuff, usually when it's a Stack though I'm too lazy to import it.

Yes, I realised afterwards that I had forgotten the parentheses.

Counter is more efficient because it makes a single linear-time pass through the data, and stores the counts in a hash table, so that in all future queries you can access the count in constant time. The count() method recomputes the count each time it is called, so uses linear time each call. So for 1000 items of data, you'd be doing about 1,000,000 operations with count() instead of 1000 with Counter. For this problem it didn't matter, as the input size is small, however for later problems in AoC you may need that linear-time efficiency.

Thank you for your clear explanation. I was wondering the same thing and it makes so much sense after reading your reply!

Hmmm, I don't remember many of the details. You could ask in the Kitatcho Discord, the devs of the game might be able to help you: discord.com/invite/Jw35VzkjCA

Nah man, I heard these skeletons used to be humans who would always applaud when their airplane lands - they must suffer for this.

Interesting approach. I'm not entirely sure how you are able to fully rule out squares larger than 31x31 having max values. It is theoretically possible a 32x32 square could be filled with 4s and 3s. But I suppose your argument is more of a statistics one: the data appears to be roughly randomly distributed, so the chances of a large square being positive-dominant is vanishingly small.

@@hextree Indeed theoretically everything is possible but in the end the power calculation is the hundred bit or zero. So the bit (or not) is [0-9] and that minus 5 give a cell power of [(-5)-4]. Statistically indeed when 300 every cell power value occurs 30 times, Because it is a well out thought calculation the theoretical maximum square must be around the 30x30 but in case of the calculation that won't occur and so the maximum square must be lower than 30x30.

@@PietWoldinga I still don't quite understand why the theoretical maximum square would be 30x30. Wouldn't it be 120x120? I.e. a square where each row has 30 4's, 30 3's, 30 2's and 30 1's.

​@@hextree That won't happen. Let's say we have 10 numbers in a row. Than by calculation we get i.e. -5, -4, -3, -2, -1, 0, 1, 2, 3, 4 or maybe -5, -4, 1, -2, -1, 0, 1, 2, 3, 4 or .. but it will be filled with an average of 1 per value. So in case of 300 digits in a row and having 10 possible values (from a well thought calculation I may presume as AoC is)(or just print the grid and you'll see) every value appears by 30 times average. In a hypothetical world there would be a square in the grid that consists of 900 4th's. But sadly this nice and beautiful hypothetical world doesn't exist we have to deal with all kinds of setbacks! So, a 30x30 square is statistically the utmost appearance of that beautiful world. A square of 3x3 is investigated in Part1 so I let my code search for 'for s in range(4, 31)' (I have a grid of 301x301 and I just don't use the zero row and column). That search will take (my laptop) me about 10 seconds. Actually that's not acceptable but hey! (I want my code to be within 2 seconds done.)

@@PietWoldinga right, but my theoretical 120x120 square is only using 30 instances of each of 4, 3, 2 and 1, so it is not exceeding the 30 average per digit per row.

Sorry, wrong copy from clipboard . I wanted to say: return {"UP": jump_state, "LEFT": run_states[0], "DOWN": run_states[1],"RIGHT": run_states[len(run_states)-1]}

Hi @lionelmidrouillet7088, thanks for your interest. Just to be clear, are you asking whether it's fine to access the final run_state using index [-1] instead of [2]? Yes, I think this would be fine. Normally, I only use the [-1] index if the list is sorted in some order, and I specifically want the one at the rightmost position. In this case I would probably prefer [2], because the list isn't in any particular order, and maybe in the future I might add new states to the list, which would cause [-1] to point to the wrong thing. Nevertheless, both methods are fine as long as you are aware of the context.

@@hextree Hi Hextree' Thanks for your answer. In fact i tried to debug your code, from this video. By using break points I saw a run_states with more than 3 records (5 exacttly). And then, if we take the run_states[2] for the RIGHT movement, we won't get the real next state for the right movement. For example, to be more clear, let's get the HURDLE_TRACK "......#...#....#....#........." and my playe'rs position 3. With this code, run_states = [] for dist in range(1 , 4): for pos in range(self.pos+1,self.pos+dist+1): if is_hurdle(pos): run_states.append(HurdleState(pos, 2)) break else: run_states.append(HurdleState(self.pos+dist, 0)) #return {"UP": jump_state, "LEFT": run_states[0], "DOWN": run_states[1],"RIGHT": run_states[2]} we will have run_states[2].pos=5 and run_states[2].stun=0 ....although, for a rght movement from 3, in this HURDLE_TRACK,we will have pos 6 and stun 2. So i tried to change: return {"RIGHT": run_states[2],"UP": jump_state, "LEFT": run_states[0], "DOWN": run_states[1]} for return {"RIGHT": run_states[len(run_states)-1],"UP": jump_state, "LEFT": run_states[0], "DOWN": run_states[1]} But... it is not a good idea. It doesnt work. The better idea - i think - to get a run_states with 3 records for the las state for each movement, is to insert else: --->>>>> if pos==self.pos+dist: run_states.append(HurdleState(self.pos+dist, 0))

it can be read at 1:26:24 , lines 30..35

Yes, the original game is required for the speedrun. And thankfully the original game seems to function better than the original Freespace 2 does. If I play the game casually I would probably opt for the port.

Nice. I can now see how it would just be a few more lines to automate all the way up to clearing the checkpoint. Yes, probably some time in the next few months I will try to clear 2021.

Yes, I am enjoying the IntCode too, I think they are very original problems and a refreshing change from what I'm used to. Did I say otherwise in the video? I can't remember. But if so, I probably meant that a sense of dread comes up when IntCode comes up, because I know I might have to use my brain for something tricky. But still overall enjoying them. Back in the Google Code Jam they sometimes had 'online algorithm' problems, which is sort of similar as you had to make continuous requests and receive responses from a black box program online.

@@hextree I think it was the dread coming through. Mainly, I've just enjoyed the IntCode problems more than the virtual machines that we've made in other years and then had to disassemble their input as the puzzle. Plus, I'm not sure how much Python I learned from those others. With the IntCode problems I've been surprised at the power of Python generators (still learning), and working on understanding coroutines. Thanks again for the vids!