![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-user-content/o/inbox%2F13641953%2Fa68a58665b6760f08a4f10415d0e989e%2Fimage.png?generation=1762391172517683&alt=media\")
We would like to thank the host and the Kaggle team for organizing such a creative and inspiring competition.\nIt was our first experience with code golf, and we learned a lot through this exciting challenge.
\nTeam Member: @chimaki821 @isakatsuyoshi @denden12 @hikari30 @kosirowada
\ntable of contents:
\nSince it was difficult for LLMs to solve tasks from scratch or fundamentally improve the algorithms, we manually created many “initial solutions”.\nDuring this process, the discussions on the forum were extremely helpful. In particular, the two discussions we posted:
\n[1] How do you golf neighbor checks? (task279)
\n[2] Diagonal Extension (task034)
\nled to productive exchanges with many participants, and we were able to incorporate the insights gained from them. We sincerely thank everyone who contributed.
\nWe focused on simplifying algorithms by observing the test cases carefully and exploiting structural patterns in the grids.\nOur main strategies were as follows:
\nany, all, zip, map, filter, and sum.list.index or enumerate over manual range loops.While solving tasks manually, we noticed that many problems shared similar structures. Recognizing these patterns allowed us to apply successful strategies from one task to another.\nThanks to @denden12, who compiled a PDF summarizing all the tasks, we were able to discover such similarities more easily.
\nFor example:
\nSince these problems were almost identical, we tackled them together and aimed for score improvements simultaneously.
\nWe racked up a lot of points by taking strong human‑written seed solutions and then “follow‑up code‑golfing” them with AIs like GPT5 Pro.
\nWe adopted this workflow for several reasons:
\nWe put significant effort into prompt design and system-level context construction.\nThe key idea was to provide good examples and rich context so that the LLM could learn how to golf effectively.
\n
These structured prompt files helped the models understand both the problem format and the essence of golfing strategies, resulting in consistently better code compression.
\nWe modified the official evaluation script to better support LLM-based experimentation:
\n p= g:(,(),{:*_:})()\n(a 46-byte snippet that passes any test case locally but fails on the leaderboard).
\nAfter collecting a sufficient number of strong initial solutions, we automated the process:
\nFor each task, we prompted the models with:
\nUsing gpt-5, gpt-5-mini, and grok-4, we performed iterative improvements.\nOn average, gpt-5 produced a few-byte improvement once every 50 problems, and gpt-5-mini once every 100 problems.
\nOur team maintained two synchronized datasets throughout the competition:
\nAfter each update or improvement, both datasets were automatically refreshed through a post-processing pipeline.
\nWe developed 23 rule-based notebooks that automatically executed sequentially every minute.\nEach notebook applied a specific transformation to further shorten the code while maintaining correctness.\nThe following summarizes the main rules used:
\nif True: blocks and remove if False: blocks entirelyTrue/False with 1/0len(x) == 0 with not xx == False with not xx == True with xpass statementsreturn None → return;list() calls for literalsl.append(x) with l += [x]from X import Y → from X import *range → R)print statementsThis automated pipeline continuously refined submissions to approach minimal byte counts.\nBy keeping these transformations modular and incremental, we ensured that even minor edits propagated safely to the latest code versions.
\nBeyond the rule-based framework, we also automated AI-based post-processing notebooks using OpenAI API, Gemini API, and Grok API.\nThese notebooks are periodically executed to perform more flexible, non-rule-based optimizations and capture improvements that purely static rules could not.
\nWe applied targeted transformations using pysearch.\nBy specifying desired input/output pairs, pysearch synthesizes the shortest logic that satisfies them, which improved scores for some problems.
\nExample:\nFor task144.py, we needed 3*(x==y) with x∈[0,7] and y∈[0,2].\npysearch rewrote it to 3>>x+y, saving 2 bytes.
Grammar optimization: Considering zlib/zopfli compression, we sometimes intentionally increased raw byte count to gain a better compressed score.\nFor example, aliasing range as R=range and using R() can reduce raw bytes, but not aliasing can compress better.\nWe first performed some of these conversions manually, then turned them into prompt examples and used GPT‑5 to revise code accordingly.
Variable-name optimization: Based on Garry Moss’s notebook\ncompressed-variable-name-optimization,\nwe accelerated and tuned the search.\nWe deferred the expensive correctness checks, first computing compressed byte counts to speed up iterations, and reset the trial counter whenever the score improved.\nIn practice, we ran the compression-aware rewrites first and then applied variable-name optimization, which yielded better overall compression efficiency.
We would like to thank the host and the Kaggle team for organizing such a creative and inspiring competition.\nIt was our first experience with code golf, and we learned a lot through this exciting challenge.
\nTeam Member: @chimaki821 @isakatsuyoshi @denden12 @hikari30 @kosirowada
\ntable of contents:
\nSince it was difficult for LLMs to solve tasks from scratch or fundamentally improve the algorithms, we manually created many “initial solutions”.\nDuring this process, the discussions on the forum were extremely helpful. In particular, the two discussions we posted:
\n[1] How do you golf neighbor checks? (task279)
\n[2] Diagonal Extension (task034)
\nled to productive exchanges with many participants, and we were able to incorporate the insights gained from them. We sincerely thank everyone who contributed.
\nWe focused on simplifying algorithms by observing the test cases carefully and exploiting structural patterns in the grids.\nOur main strategies were as follows:
\nany, all, zip, map, filter, and sum.list.index or enumerate over manual range loops.While solving tasks manually, we noticed that many problems shared similar structures. Recognizing these patterns allowed us to apply successful strategies from one task to another.\nThanks to @denden12, who compiled a PDF summarizing all the tasks, we were able to discover such similarities more easily.
\nFor example:
\nSince these problems were almost identical, we tackled them together and aimed for score improvements simultaneously.
\nWe racked up a lot of points by taking strong human‑written seed solutions and then “follow‑up code‑golfing” them with AIs like GPT5 Pro.
\nWe adopted this workflow for several reasons:
\nWe put significant effort into prompt design and system-level context construction.\nThe key idea was to provide good examples and rich context so that the LLM could learn how to golf effectively.
\n
These structured prompt files helped the models understand both the problem format and the essence of golfing strategies, resulting in consistently better code compression.
\nWe modified the official evaluation script to better support LLM-based experimentation:
\n p= g:(,(),{:*_:})()\n(a 46-byte snippet that passes any test case locally but fails on the leaderboard).
\nAfter collecting a sufficient number of strong initial solutions, we automated the process:
\nFor each task, we prompted the models with:
\nUsing gpt-5, gpt-5-mini, and grok-4, we performed iterative improvements.\nOn average, gpt-5 produced a few-byte improvement once every 50 problems, and gpt-5-mini once every 100 problems.
\nOur team maintained two synchronized datasets throughout the competition:
\nAfter each update or improvement, both datasets were automatically refreshed through a post-processing pipeline.
\nWe developed 23 rule-based notebooks that automatically executed sequentially every minute.\nEach notebook applied a specific transformation to further shorten the code while maintaining correctness.\nThe following summarizes the main rules used:
\nif True: blocks and remove if False: blocks entirelyTrue/False with 1/0len(x) == 0 with not xx == False with not xx == True with xpass statementsreturn None → return;list() calls for literalsl.append(x) with l += [x]from X import Y → from X import *range → R)print statementsThis automated pipeline continuously refined submissions to approach minimal byte counts.\nBy keeping these transformations modular and incremental, we ensured that even minor edits propagated safely to the latest code versions.
\nBeyond the rule-based framework, we also automated AI-based post-processing notebooks using OpenAI API, Gemini API, and Grok API.\nThese notebooks are periodically executed to perform more flexible, non-rule-based optimizations and capture improvements that purely static rules could not.
\nWe applied targeted transformations using pysearch.\nBy specifying desired input/output pairs, pysearch synthesizes the shortest logic that satisfies them, which improved scores for some problems.
\nExample:\nFor task144.py, we needed 3*(x==y) with x∈[0,7] and y∈[0,2].\npysearch rewrote it to 3>>x+y, saving 2 bytes.
Grammar optimization: Considering zlib/zopfli compression, we sometimes intentionally increased raw byte count to gain a better compressed score.\nFor example, aliasing range as R=range and using R() can reduce raw bytes, but not aliasing can compress better.\nWe first performed some of these conversions manually, then turned them into prompt examples and used GPT‑5 to revise code accordingly.
Variable-name optimization: Based on Garry Moss’s notebook\ncompressed-variable-name-optimization,\nwe accelerated and tuned the search.\nWe deferred the expensive correctness checks, first computing compressed byte counts to speed up iterations, and reset the trial counter whenever the score improved.\nIn practice, we ran the compression-aware rewrites first and then applied variable-name optimization, which yielded better overall compression efficiency.