# 1st place write-up: Code Golf International First and foremost, we are very grateful to the organizers of the competition for such a unique opportunity to engage in competitive code golf with the broader Kaggle community. The last three months have been a thrilling experience for all of us, and finishing in first is a tremendous honor. Overview Solutions Our code repository is [here](https://github.com/Seek64/NeurIPS-Code-Golf-2025) . The final contest submission was from [this commit](https://github.com/Seek64/NeurIPS-Code-Golf-2025/tree/9a5d156eabdc35732688751c091bf57277f70c21) . To reproduce our entry, you can download the repo and simply run python auto_zip.py , which will create the submission.zip file. Approach Our team consisted of 5 experienced code golfers. Our approach to this competition was very manual, with all solutions authored by hand. The only important automation was zlib-based compression, which applied to 21 of the 400 tasks (more on that below). Results Our good results in the competition can be mainly attributed to expertise in golfing and a large investment of time. To help understand the time investment, the average task might take a few hours to hand-optimize to a high level (including time of both the original author and people who reviewed), plus many tasks needed to be revisited as we discovered new or improved techniques. Multiplying by 400 tasks and it becomes quite an undertaking, even for a team of 5 splitting the work. The competition was extremely close among the top 3 teams, and there is no particular technique or strategy we possessed that gave a decisive advantage over 2nd or 3rd. Indeed, reviewing others' solutions post-competition, we missed some useful techniques that the other teams had. Techniques Because all the problems are grid-based, there were many recurring techniques in our solutions. In this section, we outline some of the highlights, focusing on techniques that were unique to this contest rather than standard Python golf knowledge. However, this is in no way a complete list: every problem was hand-optimized and so there are many unique tricks. Short grid operations Because these operations are quite short, they were essential building blocks of solutions. Grid operations zip(*g) transposes the grid g[::-1] vertically mirrors the grid zip(*g[::-1]) rotates 90 degrees sum(g,[]) flattens the 2-d grid to a 1-d list. Note that in many cases sum(g,g) could be used to save a byte. filter(any,g) removes empty rows Row operations min , max , any , all , and sorted built-in functions were used ubiquitously. For min , max , and sorted , the key argument was often utilized, e.g., to get the least/most common color. {}.fromkeys(r) will get the unique colors, sorted in order of first appearance. Alternatively, a dict comprehension could be used: {v:0for v in r} filter(int,r) removes black cells Recursion and loops Another fundamental building block was using recursion or loops to repeat operations. Many solutions are of the form "do operation X, rotate 90 degrees, repeat 3 more times". The baseline recursion template is p=lambda g,n=3:-n*g or F(p(g,n-1)) , taking advantage that -n*g is falsy for n=0...3 . This is more efficient than writing out a loop such as for n in range(4) . In special cases, there are shorter methods or useful alternatives: If the recursion is just depth 2, then one can write p=lambda g,h=0:F(h or p(g,g)) , saving 4 bytes in most cases. The variation p=lambda g,*h:F(*h or p(*g)) saves another 2 bytes but removes the first row. Depth 2 recursion with transposition could sometimes be done as p=lambda g:[*map(F:=lambda*r:...,*map(F,*g))] , saving 1 more byte. If the grid is fixed height, then there's a "slice recursion" technique, where you double the grid with each iteration and use a slice to stop the recursion when the desired depth is reached: p=lambda g:F(g[70:]or p(g*2)) will iterate 4 times on a 10x10 grid. This saves bytes because it eliminates extra arguments to p . For example, [task 093](https://arcprize.org/play?task=4093f84a) uses p=lambda g:g[57330:]or ... to iterate 12 times over a 14x14 grid, because 57330 = 14 * (2^12 - 1). As an alternative to recursion, there's a trick to make short loops: p=lambda g:[g:=F(g)for _ in g][3] . This is useful when g needs to be used multiple times inside F . exec/eval can be used with string multiplication to repeat code, e.g., exec("F(x);"*9) . It's very situational whether it's useful, but it can lead to small byte saves in a number of cases. An example is [task 007](https://arcprize.org/play?task=05269061) : ![](assets/b744edf9d7316a0fdd0d8c7b.png) p= g:(*) In this task, there is a pattern that repeats with length 3, and we must fill in the missing cells. To do so, we take the maximum element of the flattened grid after slicing by steps of 3, and we mutate the grid so that we can always use the same slice, avoiding any need for loop variables. Because the grid is always 7x7, we can use string multiplication with eval to do each cell operation 7 times and each row operation 7 times. List comprehensions The most common structure of our solutions was to use a list comprehension to transform the grid. The most basic form of the code will look like this: p= g:[[F(x) x r] r g] This operates on single cells only, which is quite limiting. To do more complex operations that require looking beyond a single cell, state variables can be introduced with the walrus := operator. For example, to include the cumulative sum of the row, one can write p= g:[(s:=)[F(x,s:=s+x) x r] r g] Initializing the state variable could sometimes be done more efficiently using map and lambda : [(a:=)[F(x,a:=...) x r)*r, (*g)] [*(*r,a=:[F(x,a:=...) x r],*g)] Another technique is mutating the list while operating on it. In particular, list.pop() was a source of multiple tricks. For example, it could facilitate "lookahead" in a list comprehension, such as testing whether a certain color appears later in the row: p= g:[[F(x, r[i:]) i,x (r)] r g] p= g:[[F(r.pop(), r) _ r*] r g] list.pop() can also implicitly reverse a list when popping from the back instead of front: p= g:[[F(r.pop()) _ r*][::-] r g] p= g:[[F(r.pop()) _ r*] r g] Regular expressions Regular expressions, in particular re.sub , are extremely powerful for concisely editing strings. Therefore, it is often shorter to convert the given input matrix into a string, perform the substitution, and convert back to a matrix using eval . Our final submission used regex in a total of 46 solutions. A simple example of regex can be seen for [Task 294](https://arcprize.org/play?task=bb43febb) : ![](assets/8ed139af5a1197ae6990eab4.png) re p= g:(re.sub(,,(g))) The above substitution replaces all gray pixels with red if they are in the middle of a diagonal of three gray pixels. Since the grid size is fixed (10x10), we know that diagonally connected pixels are 34 characters apart. For more complex drawing tasks, a rotate-and-replace strategy was often used: p= g:[g:=(re.sub(,,)) _ g][] We employed different variations of this approach (list comprehension, recursion, or loops) depending on the task. An interesting trick we found to save one byte is that f-strings allow unpacking, i.e., f"{*zip(*g[::-1]),}" vs str([*zip(*g[::-1])]) . In some of the most complex tasks, we utilized multiple substitutions with different expressions. One way of doing so is: p= g:[g:=(re.sub(*s,)) s [(,)]*+[(,)]*][-] Because the result after re.sub is eval ed, the replacement could be any Python expression. This was a source for some interesting tricks. For example, in [task 154](https://arcprize.org/play?task=6855a6e4) , we use the replacement *[\g<0>][::-1] to reverse the matched substring. ![](assets/50b573193bf77113e9049b28.png) re p= g,k=:(re.sub(*+,,)) "Dimension" recursion A conceptually difficult but very powerful technique is to re-use the function p for different shapes of input: a 2d grid ( list[list[int]] ), 1d row ( list[int] ), or 0d cell ( int ). This can lead to significant savings in cases where the 2d operation and 1d operation can use overlapping code. There are several variations, but one template is p= g:g*!=[p(r) r g] F(g) where F is the int -> int operation. The condition g*0!=0 checks if the input is a list, and separates the 2d/1d cases from the int case. For example, [task 021](https://arcprize.org/play?task=1190e5a7) : ![](assets/0543cccba30f8506272b3223.png) p= g:g*-*-[p(g:=r) r g g!=r][::] In this task, the row and column operations can use the exact same code: skip identical consecutive elements and downsample by 2. Note that the formula g*-1*-1 can be used here instead of g*0!=0 because cells never have value 0 (black) in this task. This technique becomes extremely potent when utilizing additional arguments to p . For example, [task 040](https://arcprize.org/play?task=2204b7a8) : ![](assets/09e87b1cff214935230d97e5.png) p= g,h=[]:g*!=[*(p,g[:]*+g[:]*,h+g)] h%~h&g The high-level idea behind this solution is to color each cell according to the nearest corner of the grid. The trick is that recursively applying g[:1]*5+g[9:]*5 will yield the colors of the nearest corners (taking advantage that the grid is always 10x10). At the end of the recursion, h will contain the current cell and g will contain the nearest corner. Note that h%~h&g is a math trick to efficiently express h and g . Guess-and-check In some problems, it is difficult to search for an object, but easy to verify whether an object is correct. As such, it is more efficient to simply keep guessing the object until the correct one is found. One example is [task 124](https://arcprize.org/play?task=53b68214) : ![](assets/2f16bf96dcf07fcaa86c424e.png) p= g,x=,y=:(G:=[(i//y*x*[]+g[i%y])[:] i ()])*(G[:]