![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F1953252%2F010fa1d41f9b192b5216869ad868be59%2FScreenshot%20from%202025-11-02%2015-02-06.png?generation=1762063336648581&alt=media\")
First, we want to thank the organizers for hosting such a competition and all the participants for battling it out with us. The past three months were exciting for us.
\nOur team’s background is mainly in competitive programming and CTF. So this competition was a step into unfamiliar territory, since we had little experience with code golf and almost none with Kaggle. In fact, it looked like many teams in this competition were also new to Kaggle. We’re a student team (someone questioned our odd team name, it's an inside pun related to our university), and we worked especially hard during our summer break in August and September.
\nThis writeup explains our approach and highlights a few interesting solutions. The visualization tool we used and our GitHub repository are listed at the end.
\nOur approach was 90% grinding code golf, 9% tooling, and 1% weird hacks. Since the 90% grind was something many teams did, we’ll just showcase two of our most memorable solutions.
\n
p= g:[[*((g,g).pop,)][-i:-i:-] i ]\niter(l.pop, n) walks l in reverse until it pops n. This task was the only one where we could exploit that behavior.
a = [,,,,,,]\n([*(,(a.pop,))]) \n(a) \n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F1953252%2Fd59ef4bdb80a7ea4ffc107f84afe9bca%2FScreenshot%20from%202025-11-02%2015-02-29.png?generation=1762063355613187&alt=media\")
re;p= g,c=-:c*g [*(*(re.sub(,,(p(g,c+)))))][::-]\nThis solution was the only one we saw that used the conditional-group syntax (?(id/name)yes-pattern|no-pattern) to change the regex pattern depending on whether a group matched.
Here are the tools and odd hacks we built along the way.
\nEven before the contest started, we suspected there would be cases where compression strategy might be used. That hunch turned out to be right. We built our own compressor and optimizer stronger than Zopfli, which is a better zlib compressor developed by Google, and lifted our score by about 700 points relative to the native zlib.
\nFirst, a quick overview of the compressed-code setup. Compressed code needs to be decompressed and executed at runtime. A key consideration is how to embed the compressed payload into the source. Python byte literals cannot contain characters ≥ 0x80, so we need to convert from another format.
\nWe handled this by embedding the payload in a string literal and converting it to bytes. In Python, the file encoding can be specified with a comment like # -*- coding: latin-1 -*- (PEP 263). The shortest form that matches the regex ^[ \\t\\f]*#.*?coding[:=][ \\t]*([-_.a-zA-Z0-9]+) is #coding:L1. L1 is an alias of the latin_1 encoding (Documentation), which maps every character from ord(0) to ord(255) directly to its byte value. Using this, the decompression stub becomes:
\n zlib\n(zlib.decompress((,)))\nWe used zlib because it fit our use case best. Python gives you zlib, lzma, and bzip. zlib and lzma are LZ77-family compressors, and bzip is based on the Burrows–Wheeler Transform. BWT can be weaker on these inputs compared to LZ77, and lzma is strong but its header overhead is large, so it didn’t beat zlib unless the code exceeded about 1000 bytes. The newer zstd will be available in Python 3.14 (Documentation), but sadly it was out of reach this time.
\nzlib is basically deflate plus a 2-byte header and a 4-byte CRC checksum. zlib.decompress() supports raw deflate when you pass a negative second argument, so zlib.decompress(code,-15) saved 6 bytes at the cost of 4 extra bytes, netting a win. For small zlib streams, zlib.decompress(code,-9) sometimes also worked, shaving another byte. Our final decompression stub looked like this:
\n zlib\n(zlib.decompress((,),-))\nBefore talking about deflate-specific optimizations, here’s the bare minimum structure. Deflate encodes data as copies of previous substrings plus single-character additions. For instance, abracadabra becomes [a][b][r][a][c][a][d][copy(distance=7,length=4)]. Think of each piece as a factor. Minimizing the number of factors is easy with a greedy approach. In practice, we must also encode those factors into a bitstream, and that coding step complicates matters. Minimizing factor count alone doesn’t always minimize the final deflate size.
For coding, deflate uses Huffman codes for literals, and for length/distance pairs. You can either use a preset Huffman tree or embed your own. In our use case, presets were inefficient, so we mostly embedded our own. Switching trees midstream is possible, but embedding a tree costs about 300 bits (~40 bytes), so one tree is typically best here. (Rarely, using the preset tree for the last block is better. But you can brute-force the boundary to easily compensate this.)
\nThere are two Huffman trees, one for literals/lengths and one for distances. These trees are themselves run-length encoded (RLE) and then encoded by another Huffman tree (the \"cl-code\") and inserted as a header.
\nWe built a visualization app for deflate(deflate-viz, repository). By attaching a deflate or zlib payload via query parameters, you can inspect the internals.
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F1953252%2Fe8762c54471c6f6c8d3f9595273d1001%2Fdeflate-viz.png?generation=1762062312506864&alt=media\")
By exploring the visualization, we got a few key insights.
\nObvious, but the golden rule of compression golf. Also loop unrolling sometimes produce better results than loops.
\nAs mentioned, the Huffman tree is represented by code lengths ordered by byte value and then RLE-compressed. Longer runs help. Python syntax doesn’t use uppercase letters, so those bytes would ideally be all zeros in the code-length stream; introducing uppercase disrupts RLE. Also, to help the literal Huffman distribution, it’s better to reuse letters that appear in common keywords like def and return, or built-ins like zip, and avoid introducing stray characters.
' over \"Again, RLE awareness. Tabs sit next to newline in ASCII and tend to disrupt RLE less than spaces. Single quotes tend to work better because ' is adjacent to (.
We first set out to produce an encoding-friendly deflate payload. Since the payload is embedded as a string, some characters require escaping, e.g., the quote characters used for the string delimiter, or \\x00. Each such character costs an extra byte; we want to avoid them. Empirically, roughly 1/100 of bytes tended to need escaping.
So we tried randomly perturbing parts of the deflate payload to dodge those characters. The most leverage comes from the embedded Huffman tree, which influences many bytes. Under an optimistic assumption that all bytes randomize independently, a ~200-byte payload would avoid escapes with probability about (99/100)^200 ≈ 0.13. Reality is less kind, so it took more trials.
We implemented a deflate parser and performed hill climbing on top of Zopfli’s output (implementation). This worked well in practice and often reduced the number of escapes to zero.
\nAlong the way, we generated payloads that beat Zopfli’s size, initially as a side effect of hill climbing to remove escapes. That suggested we might actually build a compressor that outperforms Zopfli.
\nThe full story is long, so details are in a teammate’s writeup(To Be Written). Here is a broad, high-level overview of the approach.
\nWe first tried improving the Huffman tree with metaheuristics like genetic algorithms and simulated annealing, but this underperformed. We suspect that this because of the search landscape wasn’t smooth, and the objective (bits) is discrete.
\nThe big breakthrough was realizing that when everything except the Huffman tree is fixed, we can compute the optimal Huffman code lengths by dynamic programming (DP). Concretely, fixing the factorization and the cl-code (the Huffman code for the Huffman codes) allows a DP to find optimal code lengths. Implementing this let us shrink the Huffman trees that Zopfli produced (implementation). Here’s a comparison:
\n\nObservation suggested variable-name assignment strongly affects compression. To mechanize this, we statically analyzed code to extract dependencies and then added a routine that reassigns variable names to improve compressibility. This was the single most impactful optimization, netting several hundred bytes overall.
\nWe also ran a GA whose state combined variable-name assignments and the deflate payload itself, interleaving factorization and Huffman optimizations. This gained around 100 bytes (implementation).
\nIt was disclosed that test cases were generated using ARC-GEN. The generator is deterministic given a seed. From arc_gen.py:
\n ():\n \n task_info = task_list.task_list()[task_num]\n _, generator, _ = task_info\n examples = []\n example_id (num_examples):\n random.seed(task_num + example_id)\n examples.append(generator())\n (examples)\nHowever, running arc_gen didn’t reproduce the exact test cases.
\nWhen the anomaly in task100 was fixed and the test cases remains as same in almost all cases, it suggested some seed mechanism was in play. We reasoned that the high quality source to leak randomness is via randint. Skipping the nerdy details, if a generator uses only calls like randint(a, b) where b - a + 1 is a power of two, those outputs can leak clean bits of the PRNG state.
We filtered ARC-GEN and identified three tasks, which is task043, task127, task142, as good candidates. From each ARC-GEN case we extracted the random sequences used.
\nLEAK_CASES = \n\n\n\n\n\ncases = get_task()[]\nleak_43 = []\n cases[:LEAK_CASES]:\n g = [] \n leak = [*(==r[-]) r g[:]] + [*(==c) c g[][:-]]\n leak_43.append(leak)\n\n\n\n\ncases = get_task()[]\nleaks_127 = []\n cases[:LEAK_CASES]:\n g = []\n leak = []\n leak.append([, ][(g)==])\n leak.extend([v- v g[][::]])\n (g) == :\n leak.extend([v- v g[][::]])\n leaks_127.append(leak)\n\n\n\n\n\n\n\ncases = get_task()[]\nleaks_142 = []\n cases[:LEAK_CASES]:\n g = []\n leak = []\n s g:\n v s:\n leak.append(v)\n leaks_142.append(leak)\n\n(leaks_127)\n(leaks_142)\n\n\nA bit of inspection shows the random sequences share the same prefixes. In other words, across all tasks, the same seed was used per index!
\nWith that in mind, we searched for seeds that would produce the sequences above.
\n i ():\n random.seed(i)\n r = [random.randint(,) i ()]\n r leak_43:\n (i, leak_43.index(r))\n\n\n\nSo the seeds were 2025 + i. This hinted we might compress some tasks dramatically by regenerating from the seed. For this to be useful, the following criteria had to be met:
By scouting tasks, only task096 fit these criteria. This tasks has tons of corner cases and was one of the hardest to optimize.
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F1953252%2F07f32fcee52b745d1bfaa82d9c4a9397%2FScreenshot%20from%202025-11-02%2014-55-16.png?generation=1762062925269548&alt=media\")
In this task, the grid width/height, background color, reticle colors, and each segment length are generated randomly. Here is a simplified version of the algorithm for those:
\n\nwidth, height = random.randint(, ), random.randint(, )\nb = random.randint(, ) \ncolors = random.sample((((, ))-{b}), random.randint(, ))\nlengths = []\n i ((colors)):\n min_length, max_length = (i + , ), i + ( i > )\n lengths.append(random.randint(min_length, max_length))\nThese are exactly the pieces of information you need to determine the seed and construct the output. Our experiments showed that width, height, the set of colors, and the background color suffice to identify the seed. And, for non-ARC-GEN train and test cases, we also found seeds via exhaustive search.
\nHere’s the code we built using this strategy:
\n random *\n ():\n seed([-l,,,,][l*(<l)])\n d,t,f=randrange(,)==(r[]),randrange(,)==(r),randrange(,)\n s=sample([*{*(,)}^{f*(l<)}],o:=randrange(,))\n u=[+randrange(<m,(m<)+m) m (o)]\n n=[(o*-)*[f] m (o)]\n m (o):\n e (u[m]):e-=m;n[e-][o+m-]=n[e-][o-m-]=n[-m-][o+e-]=n[-m-][o-e-]=s[m]\n ([d,t,{*(r,[])}=={*s,f},f r[]]) n+n[:-][::-] p(r,l-)\nAfter compression this ended up at best+48, which is not quite we are looking for, but we’re proud we had this kind of solution.
\nGiven the marathon nature of the contest, we built QoL tooling: mainly CI/CD and a local Web UI.
\nOn every push (and on schedules) we ran jobs to do the following.
\nWe generated a stats summary in Markdown as the README. Later the Web UI replaced it, but it was handy on the go.
\nWe auto-updated banners in files to show size targets like this:
\n\n\nWe notified our Discord on every teammate push. This made it easy to spot missed shrink opportunities and pick the low-hanging fruit.
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F1953252%2F90c30fbaaf30f328ef51bfaf7c12565a%2FScreenshot%20from%202025-11-02%2004-48-08.png?generation=1762063444300991&alt=media\")
We automatically updated the best-known sizes referenced by the banners and Web UI.
\nWe've created(99% vibe-coded) local Web UI for daily golfing.
\nWe could track our progress. A histogram highlighted which tasks deserved compression attention.
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F1953252%2Fc90f52efe70694f4c7f046da468feb80%2FScreenshot%20from%202025-11-02%2014-58-05.png?generation=1762063098220077&alt=media\")
Thumbnail overview, color-coded by delta from best. We added manual tags and search.
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F1953252%2F92816db89d2e92b34f4b87b2c796d66d%2FScreenshot%20from%202025-11-02%2014-58-59.png?generation=1762063151089124&alt=media\")
As shown: tags and code, all cases, and score trajectories by team. We also added a “Open current best in VSCode” button.
\n![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F1953252%2Fc0dac6489524be375907ed0ad9b9008a%2FScreenshot%20from%202025-11-02%2014-59-49.png?generation=1762063195601066&alt=media\")
Integrated with checker.py to show the latest run results. Passing values through the identity function DUMP printed its argument, which helped debug recursive solutions.
![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F1953252%2Fd2a18ffb82a338e5ac9eb4576d4aaaf6%2FScreenshot%20from%202025-11-02%2015-00-06.png?generation=1762063212521821&alt=media\")
__eq__ that was published in mid-August. Our short version was:class p:__init__=help;__eq__=anyOur competition repository (very messy; it wasn’t meant to be public) is here:
\nhttps://github.com/key-moon/golf
\nRepository overview:
\ndist: resultsbase_[name]: each member’s “golf course”If you want to run anything, execute source tools/setup.sh to set up the environment.
Wow I had completely overlooked trying to optimize the huffman tree since I thought it would only end up saving only a few bits in most cases, but we did write a DP to optimize the LZ77 for minimizing the escaped size rather than the raw size (implementation).
", "votes": 3, "replies": [] }, { "id": 3310137, "author_name": "hellopir2", "author_url": "", "post_date": "2025-11-02T06:48:15.453000", "content": "lol, we contemplated using the seed but didn't bother once the default ones didn't work. cool to see that it's actually possible though.
\nlooks like that task 270 solution can be used for a 114b diamond
\n re;p= g:(*) g\nSeed cracking is crazy.
", "votes": 0, "replies": [] }, { "id": 3310529, "author_name": "Aaditya Khanal", "author_url": "", "post_date": "2025-11-03T06:16:02.230000", "content": "This is an absolutely incredible writeup! The depth of optimization and creativity with deflate compression is mind-blowing. Thank you for sharing all these insights!
", "votes": 0, "replies": [] } ], "comment_count": 4, "messages": [ { "id": 3310116, "postDate": "2025-11-02T06:06:23.613Z", "content": "First, we want to thank the organizers for hosting such a competition and all the participants for battling it out with us. The past three months were exciting for us.
\nOur team’s background is mainly in competitive programming and CTF. So this competition was a step into unfamiliar territory, since we had little experience with code golf and almost none with Kaggle. In fact, it looked like many teams in this competition were also new to Kaggle. We’re a student team (someone questioned our odd team name, it's an inside pun related to our university), and we worked especially hard during our summer break in August and September.
\nThis writeup explains our approach and highlights a few interesting solutions. The visualization tool we used and our GitHub repository are listed at the end.
\nOur approach was 90% grinding code golf, 9% tooling, and 1% weird hacks. Since the 90% grind was something many teams did, we’ll just showcase two of our most memorable solutions.
\n
p= g:[[*((g,g).pop,)][-i:-i:-] i ]\niter(l.pop, n) walks l in reverse until it pops n. This task was the only one where we could exploit that behavior.
a = [,,,,,,]\n([*(,(a.pop,))]) \n(a) \n
re;p= g,c=-:c*g [*(*(re.sub(,,(p(g,c+)))))][::-]\nThis solution was the only one we saw that used the conditional-group syntax (?(id/name)yes-pattern|no-pattern) to change the regex pattern depending on whether a group matched.
Here are the tools and odd hacks we built along the way.
\nEven before the contest started, we suspected there would be cases where compression strategy might be used. That hunch turned out to be right. We built our own compressor and optimizer stronger than Zopfli, which is a better zlib compressor developed by Google, and lifted our score by about 700 points relative to the native zlib.
\nFirst, a quick overview of the compressed-code setup. Compressed code needs to be decompressed and executed at runtime. A key consideration is how to embed the compressed payload into the source. Python byte literals cannot contain characters ≥ 0x80, so we need to convert from another format.
\nWe handled this by embedding the payload in a string literal and converting it to bytes. In Python, the file encoding can be specified with a comment like # -*- coding: latin-1 -*- (PEP 263). The shortest form that matches the regex ^[ \\t\\f]*#.*?coding[:=][ \\t]*([-_.a-zA-Z0-9]+) is #coding:L1. L1 is an alias of the latin_1 encoding (Documentation), which maps every character from ord(0) to ord(255) directly to its byte value. Using this, the decompression stub becomes:
\n zlib\n(zlib.decompress((,)))\nWe used zlib because it fit our use case best. Python gives you zlib, lzma, and bzip. zlib and lzma are LZ77-family compressors, and bzip is based on the Burrows–Wheeler Transform. BWT can be weaker on these inputs compared to LZ77, and lzma is strong but its header overhead is large, so it didn’t beat zlib unless the code exceeded about 1000 bytes. The newer zstd will be available in Python 3.14 (Documentation), but sadly it was out of reach this time.
\nzlib is basically deflate plus a 2-byte header and a 4-byte CRC checksum. zlib.decompress() supports raw deflate when you pass a negative second argument, so zlib.decompress(code,-15) saved 6 bytes at the cost of 4 extra bytes, netting a win. For small zlib streams, zlib.decompress(code,-9) sometimes also worked, shaving another byte. Our final decompression stub looked like this:
\n zlib\n(zlib.decompress((,),-))\nBefore talking about deflate-specific optimizations, here’s the bare minimum structure. Deflate encodes data as copies of previous substrings plus single-character additions. For instance, abracadabra becomes [a][b][r][a][c][a][d][copy(distance=7,length=4)]. Think of each piece as a factor. Minimizing the number of factors is easy with a greedy approach. In practice, we must also encode those factors into a bitstream, and that coding step complicates matters. Minimizing factor count alone doesn’t always minimize the final deflate size.
For coding, deflate uses Huffman codes for literals, and for length/distance pairs. You can either use a preset Huffman tree or embed your own. In our use case, presets were inefficient, so we mostly embedded our own. Switching trees midstream is possible, but embedding a tree costs about 300 bits (~40 bytes), so one tree is typically best here. (Rarely, using the preset tree for the last block is better. But you can brute-force the boundary to easily compensate this.)
\nThere are two Huffman trees, one for literals/lengths and one for distances. These trees are themselves run-length encoded (RLE) and then encoded by another Huffman tree (the \"cl-code\") and inserted as a header.
\nWe built a visualization app for deflate(deflate-viz, repository). By attaching a deflate or zlib payload via query parameters, you can inspect the internals.
\n
By exploring the visualization, we got a few key insights.
\nObvious, but the golden rule of compression golf. Also loop unrolling sometimes produce better results than loops.
\nAs mentioned, the Huffman tree is represented by code lengths ordered by byte value and then RLE-compressed. Longer runs help. Python syntax doesn’t use uppercase letters, so those bytes would ideally be all zeros in the code-length stream; introducing uppercase disrupts RLE. Also, to help the literal Huffman distribution, it’s better to reuse letters that appear in common keywords like def and return, or built-ins like zip, and avoid introducing stray characters.
' over \"Again, RLE awareness. Tabs sit next to newline in ASCII and tend to disrupt RLE less than spaces. Single quotes tend to work better because ' is adjacent to (.
We first set out to produce an encoding-friendly deflate payload. Since the payload is embedded as a string, some characters require escaping, e.g., the quote characters used for the string delimiter, or \\x00. Each such character costs an extra byte; we want to avoid them. Empirically, roughly 1/100 of bytes tended to need escaping.
So we tried randomly perturbing parts of the deflate payload to dodge those characters. The most leverage comes from the embedded Huffman tree, which influences many bytes. Under an optimistic assumption that all bytes randomize independently, a ~200-byte payload would avoid escapes with probability about (99/100)^200 ≈ 0.13. Reality is less kind, so it took more trials.
We implemented a deflate parser and performed hill climbing on top of Zopfli’s output (implementation). This worked well in practice and often reduced the number of escapes to zero.
\nAlong the way, we generated payloads that beat Zopfli’s size, initially as a side effect of hill climbing to remove escapes. That suggested we might actually build a compressor that outperforms Zopfli.
\nThe full story is long, so details are in a teammate’s writeup(To Be Written). Here is a broad, high-level overview of the approach.
\nWe first tried improving the Huffman tree with metaheuristics like genetic algorithms and simulated annealing, but this underperformed. We suspect that this because of the search landscape wasn’t smooth, and the objective (bits) is discrete.
\nThe big breakthrough was realizing that when everything except the Huffman tree is fixed, we can compute the optimal Huffman code lengths by dynamic programming (DP). Concretely, fixing the factorization and the cl-code (the Huffman code for the Huffman codes) allows a DP to find optimal code lengths. Implementing this let us shrink the Huffman trees that Zopfli produced (implementation). Here’s a comparison:
\n\nObservation suggested variable-name assignment strongly affects compression. To mechanize this, we statically analyzed code to extract dependencies and then added a routine that reassigns variable names to improve compressibility. This was the single most impactful optimization, netting several hundred bytes overall.
\nWe also ran a GA whose state combined variable-name assignments and the deflate payload itself, interleaving factorization and Huffman optimizations. This gained around 100 bytes (implementation).
\nIt was disclosed that test cases were generated using ARC-GEN. The generator is deterministic given a seed. From arc_gen.py:
\n ():\n \n task_info = task_list.task_list()[task_num]\n _, generator, _ = task_info\n examples = []\n example_id (num_examples):\n random.seed(task_num + example_id)\n examples.append(generator())\n (examples)\nHowever, running arc_gen didn’t reproduce the exact test cases.
\nWhen the anomaly in task100 was fixed and the test cases remains as same in almost all cases, it suggested some seed mechanism was in play. We reasoned that the high quality source to leak randomness is via randint. Skipping the nerdy details, if a generator uses only calls like randint(a, b) where b - a + 1 is a power of two, those outputs can leak clean bits of the PRNG state.
We filtered ARC-GEN and identified three tasks, which is task043, task127, task142, as good candidates. From each ARC-GEN case we extracted the random sequences used.
\nLEAK_CASES = \n\n\n\n\n\ncases = get_task()[]\nleak_43 = []\n cases[:LEAK_CASES]:\n g = [] \n leak = [*(==r[-]) r g[:]] + [*(==c) c g[][:-]]\n leak_43.append(leak)\n\n\n\n\ncases = get_task()[]\nleaks_127 = []\n cases[:LEAK_CASES]:\n g = []\n leak = []\n leak.append([, ][(g)==])\n leak.extend([v- v g[][::]])\n (g) == :\n leak.extend([v- v g[][::]])\n leaks_127.append(leak)\n\n\n\n\n\n\n\ncases = get_task()[]\nleaks_142 = []\n cases[:LEAK_CASES]:\n g = []\n leak = []\n s g:\n v s:\n leak.append(v)\n leaks_142.append(leak)\n\n(leaks_127)\n(leaks_142)\n\n\nA bit of inspection shows the random sequences share the same prefixes. In other words, across all tasks, the same seed was used per index!
\nWith that in mind, we searched for seeds that would produce the sequences above.
\n i ():\n random.seed(i)\n r = [random.randint(,) i ()]\n r leak_43:\n (i, leak_43.index(r))\n\n\n\nSo the seeds were 2025 + i. This hinted we might compress some tasks dramatically by regenerating from the seed. For this to be useful, the following criteria had to be met:
By scouting tasks, only task096 fit these criteria. This tasks has tons of corner cases and was one of the hardest to optimize.
\n
In this task, the grid width/height, background color, reticle colors, and each segment length are generated randomly. Here is a simplified version of the algorithm for those:
\n\nwidth, height = random.randint(, ), random.randint(, )\nb = random.randint(, ) \ncolors = random.sample((((, ))-{b}), random.randint(, ))\nlengths = []\n i ((colors)):\n min_length, max_length = (i + , ), i + ( i > )\n lengths.append(random.randint(min_length, max_length))\nThese are exactly the pieces of information you need to determine the seed and construct the output. Our experiments showed that width, height, the set of colors, and the background color suffice to identify the seed. And, for non-ARC-GEN train and test cases, we also found seeds via exhaustive search.
\nHere’s the code we built using this strategy:
\n random *\n ():\n seed([-l,,,,][l*(<l)])\n d,t,f=randrange(,)==(r[]),randrange(,)==(r),randrange(,)\n s=sample([*{*(,)}^{f*(l<)}],o:=randrange(,))\n u=[+randrange(<m,(m<)+m) m (o)]\n n=[(o*-)*[f] m (o)]\n m (o):\n e (u[m]):e-=m;n[e-][o+m-]=n[e-][o-m-]=n[-m-][o+e-]=n[-m-][o-e-]=s[m]\n ([d,t,{*(r,[])}=={*s,f},f r[]]) n+n[:-][::-] p(r,l-)\nAfter compression this ended up at best+48, which is not quite we are looking for, but we’re proud we had this kind of solution.
\nGiven the marathon nature of the contest, we built QoL tooling: mainly CI/CD and a local Web UI.
\nOn every push (and on schedules) we ran jobs to do the following.
\nWe generated a stats summary in Markdown as the README. Later the Web UI replaced it, but it was handy on the go.
\nWe auto-updated banners in files to show size targets like this:
\n\n\nWe notified our Discord on every teammate push. This made it easy to spot missed shrink opportunities and pick the low-hanging fruit.
\n
We automatically updated the best-known sizes referenced by the banners and Web UI.
\nWe've created(99% vibe-coded) local Web UI for daily golfing.
\nWe could track our progress. A histogram highlighted which tasks deserved compression attention.
\n
Thumbnail overview, color-coded by delta from best. We added manual tags and search.
\n
As shown: tags and code, all cases, and score trajectories by team. We also added a “Open current best in VSCode” button.
\n
Integrated with checker.py to show the latest run results. Passing values through the identity function DUMP printed its argument, which helped debug recursive solutions.
__eq__ that was published in mid-August. Our short version was:class p:__init__=help;__eq__=anyOur competition repository (very messy; it wasn’t meant to be public) is here:
\nhttps://github.com/key-moon/golf
\nRepository overview:
\ndist: resultsbase_[name]: each member’s “golf course”If you want to run anything, execute source tools/setup.sh to set up the environment.
lol, we contemplated using the seed but didn't bother once the default ones didn't work. cool to see that it's actually possible though.
\nlooks like that task 270 solution can be used for a 114b diamond
\n re;p= g:(*) g\nSeed cracking is crazy.
", "rawMarkdown": "Seed cracking is crazy." }, { "id": 3310529, "postDate": "2025-11-03T06:16:02.230Z", "content": "This is an absolutely incredible writeup! The depth of optimization and creativity with deflate compression is mind-blowing. Thank you for sharing all these insights!
", "rawMarkdown": "This is an absolutely incredible writeup! The depth of optimization and creativity with deflate compression is mind-blowing. Thank you for sharing all these insights!" } ], "complete": true, "source": "live", "fetched_at": "2026-10-19T12:51:29Z", "competition_id": 95282, "competition_slug": "google-code-golf-2025", "team_id": 14194523, "solution_url": "/competitions/google-code-golf-2025/writeups/himagine-the-future-5th-place-writeup" }