# 8th place write-up: import itertools ![](assets/dfc6e5ddf8bb96c624a2ce48.webp) Introduction We’d like to begin by thanking the organizers [@mmoffitt](https://www.kaggle.com/mmoffitt) and all our fellow competitors we’ve shared the last three months with. It’s been a lot of work—especially for a mostly manual, mostly non-expert benchmark team like us—but we’re very happy with where we ended up on the leaderboard. We genuinely worked our behinds off to get there. You can find our solutions, compression scripts and other interesting things at this link: [https://github.com/Natanaelel/GoogleCodeGolf2025](https://github.com/Natanaelel/GoogleCodeGolf2025) Approach Like many other teams, we manually worked on each task, so we didn’t have a secret trick that suddenly cut dozens of bytes. Our final result was the sum of many small insights we picked up along the way. Since most of us came into this with little to no code-golf experience, our first instinct was to lean heavily on LLMs. It didn’t take long to realize it was not going to get us anywhere near the top in what was already a very saturated field just a few weeks in. Solutions / techniques overwiew Recursion, cell automata, pysearch - task002 In this task we have to fill all regions closed by green borders with yellow color. There are many ways to solve this task. The simplest way is straightforward DFS/Flood-fill algorithm. Another approach is to look only at 2 cells at a time and set value of current cell based on neighbor's value, almost like [Cellular automata](https://en.wikipedia.org/wiki/Cellular_automaton) . You just need to do enough iterations (using recursion to save bytes) while rotating array after each step to take care of neighbor pairs in each orientation. p= g,i=:-i*g p([[-%(**i|b ~a%) a,b ([]+r,r)]*r, (*g[::-])],i-) There are 3 important parts here: recursion template p=lambda g,i=67:-i*g or p(...,i-1) how do you access the neighbor pair, we used pretty simple for a,b in zip([4]+r,r) how do you calculate new value based on condition, we flood from the side for all iterations except last one and then swap colors in the last step using 4-4%(0**i|b or~a%9 that was figured out with help of tool called [pysearch](https://github.com/lynn/pysearch) by lynn. Those parts can be done in many different ways. And there are many more tricks to be used here that you can find by looking at top teams solutions. Task002 animation, keep in mind that rotations are not shown so it's easier to follow what is happening (steps go from 67 to -1). ![](assets/85e58d1914c24a2ce21f3c61.gif) Loop trick instead of recursion template - task095 We used recursion template shown above in many tasks, but turns out that if number of iterations is smaller than grid size and we don't need to make calculations based on the counter we can use shorter template used below. What is also interesting here is that parameter b could be just lambda parameter even though technically it should be set to zero before processing each row. p= g,b=:[g:=[[b%|(b:=a) a r] r (*g[::-])] _ g][] Iterating while mutating using pop() - task214 ![](assets/1e5c60aa4df66e96a878164f.png) In this task we have to finish pattern located in the left square. p= g:[r+g.pop()[::-] r,*r[:] (g*,*g[::-])] There are a couple of interesting tricks used here: g.pop() that returns last row from g g*1 to make a shallow copy so we can still iterate over full g even though g.pop() is mutating g ( zip(g*1,*g[::-1]) if resolved before any pop() ) Recursion with a*0==0 trick - task021 There were tasks that could be solved in a way that we perform the same operation both for whole row and for single number in a row. So we needed a way to test if current value is a row or a number. We can take advantage of the fact that: list * 0 = [] number * 0 = 0 p= g:(g[g.count(a:=g[])-:])*[a*(a*==) p(a)] If a*0==0 is true then we return a (number) Otherwise we recurse with or p(a) branch. Loop flattening and bitwise operations - task365. ![](assets/9ea1122c932f96ef59389142.png) The goal of this task is to find the rectangle with the most red pixels. We can achieve it by simply brute forcing all possible candidates using 4 loops over coordinates i,j and sizes w,h . For this task it's enough if each loop is from 0 to 7, that means we can alias R=range(8) and use 4 loops. R=() p= g:(((s:=(m:=[r[j:][:w] r g[i:][:h]],[])).count()*(s),(s),m) i R j R w R h R)[] But we can also flatten all 4 loops into single one and take advantage of the fact that 8 is power of 2 so we can calculate i,j,w,h using bitwise operations (instead of // and % arithmetic). p= g:(((s:=(m:=[x[t&:][:t>>&] x g[t>>&:][:t>>]],g))*s.count(),(s),m) t ())[] Using hash to deal with edge cases - task070 There were tasks that could be solved simple way but failed 1 or 2 edge cases. So there were 2 options: use longer more reliable solution hash / hardcode that 1-2 edge cases and use the simpler solution Here we use hash((*c,))%709==8 that calculates hash of column (as tuple) to detect that edge case so we can apply additional logic so solution pass all test cases. p= g:[[x+*(x< r)*(((*c,))%== c)*c,x (*g,r)] r g] Flattening array - task286 ![](assets/dd0046bad94e592d3861d3a0.gif) This is another task that uses recursion+rotation template. If the current cell is empty and neighbor has one of 2 maze colors, then current cell will have the other color. To find the other color we can flatten the 2D array into 1D array using sum(g,[]) , then we can convert to set to figure out the color that we need (the only colors possible are black, cyan (wall color), neighbor color (that we know) and other color (that we are looking for)). Also interesting trick to save 1b is to set initial value of sum to e.g. r instead of [] to save a byte. p= g,k=:-k*g p([[b a% ({*(g,r)})-a- a,b ([]+r,r)]*r, (*g[::-])],k-) Iterating over raw bytes - task317 The most obvious solution for task317 is quite simple, we just use list comprehension and for each position we check the closest center of 3x3 square. ![](assets/1644e265f39058175ded0cb6.png) R=[,,,,,,,,] p= g:[[) <<(k:=k+) a,b (r,[]+r)]*r, (*g[::-])],k-) Bruteforcing solution to avoid bad test cases - task346 ![](assets/f0eeea3d656a014a7c0973bc.png) I In this task we have to return 1x1 array with color that is inside a different color square in input array. The simplest solution would be to try to return the least common color using this solution: p= g:[[(S:=(g,[]),key=S.count)]] But there is good news and bad news. The bad news is that it fails 3 test cases. The good news is that it fails 3 test cases, so maybe we can make a slight code modifications to make all tests pass. The general idea is to look at failing cases and try to figure out how we can modify parameters of sum function so it will produce expected result. We did it by trial and error with a help a tiny bruteforce script. p= g:[[(S:=(g[:]+g[:],[]),key=S.count)]] The simple script we used, we tried different templates. i (): j (i+,): (i,j) k (): solution= verify_program(task_num, solution, task_data): (solution) Unfortunately we still missed the shortest possible solution that was really close. Regex is quite powerful - task017 ![](assets/67c5f3723e1d54d7987a865c.gif) The idea was to rotate the grid, then use a regex to look for a sequence of five non-zero values followed by a zero. If that exact 5-value pattern appears again later in the grid, we replace the zero with whatever value follows the second occurrence. We repeat this until all the gaps are filled. This solution was a kind of catalyst for the team to realize regex makes reasoning about some types of tasks a lot easier. It gave some of us the motivation to read the regex manual more carefully. re p= g,k=:-k*g p((re.sub(,,([*(*g[::-])]))),k-) Compression optimizations - task238 Many of our solutions ended up being long enough that compressing them was a viable way to shorten them. For this, we based our initial compression script on the ones that were shared publicly and improved them by adding more variants of zlib and zopfli compression levels, with or without blocksplitting, and setting the number of iterations to a specific value in the range 1-100. We also made heavy use of the variable optimization notebook [https://www.kaggle.com/code/garrymoss/compressed-variable-name-optimization](https://www.kaggle.com/code/garrymoss/compressed-variable-name-optimization) by [@garrymoss](https://www.kaggle.com/garrymoss) , thanks a lot for sharing it. While far from optimal (-28b) from diamond in the end. The solution for task238 is a very silly example of why compression golfing has a completely different approach than normal golfing. We had this code that compressed from the original 281b to 251b (): f= f:[[*e] e (*(f,(*t))) f(e)];r=f( e:({*e}-{})) f,e (f( e: e)): p,n (e):d=(e);r[f+][p+]=n (f