0% found this document useful (0 votes)
55 views3 pages

ARC Challenge: DSL Solution Overview

Uploaded by

yifu.chen
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
55 views3 pages

ARC Challenge: DSL Solution Overview

Uploaded by

yifu.chen
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

DSL solution to the ARC challenge

Johan Sokrates Wind


June 2020

1 Contestant
Competition name: Abstraction and Reasoning Challenge

Team name: icecuber


Private leaderboard score: 0.794
Private leaderboard place: 1st

Author: Johan Sokrates Wind


Location: Tromsø, Norway
Email: top-quarks@[Link]

2 About the author


I hold a master’s degree in Industrial Mathematics from Norwegian University
of Science and Technology. However, I believe my experience with competi-
tive programming (CP) was more useful for this contest. CP has trained me
to quickly and efficiently write simple algorithms such as flood fill, dynamic
programming and Huffman coding. Since a large part of my solution was gener-
alizing and implementing image transformations, and run-time performance was
important, this fit my skills well. Larger projects I’ve done (like implementing
visual odometry on a mobile phone, and the TrackML Kaggle contest) were also
useful, as they helped me structure my code in a way that allows adding new
ideas easily.
The aim of measuring AGI intrigued me into trying the competition. The
format also fit me well, because I could write an efficient solution from scratch,
and there were no well established approaches to solve it.
I worked on and off from the start of the competition. If I had to guess, I
would estimate a bit over a month of full time work went into it in total.

3 Summary of approach
The main component of my solution is a DSL which applies up to 4 of 142 unary
transformations (based on 42 different functions, where some have multiple vari-

1
ants). I enumerate the transformations efficiently by reducing duplicates, and
then combine them by greedily stacking them to fit training samples. Every-
thing is implemented efficiently in C++ (with no dependencies) and running in
parallel. A simple scheduler tries to use the 9 hour / 16 GB memory budget
fully.

4 Transformation selection / engineering


The most important image transformations:

• Cut (image) → list of images


Tries to figure out a background color and splits the remaining pixels into
corner connected groups.
• filterCol (image, color) → image
Erases all colors except the given one (sets them to 0).

• colShape (image, color) → image


Change all non-zero pixels to ”color”.
• composeGrowing (list of images) → image
Stack the list of images on top of each other, treating 0 as transparent.
The image with the fewest non-zero pixels is at the top.

• compress (image) → image


Extract minimal sub-image containing all non-zero pixels.
• rigid (image, id) → image
Perform rotation (0/90/180/270 degrees) and/or flip.

• pickMax (list of images, id) → image


Extract the image with maximum property, for example id = 0 extracts
the image with the most non-zero pixels.
I constructed transformations by hand-solving 100 training tasks and 100
evaluation tasks, and then extracting useful functions. Generalizing when it
seemed reasonable (like adding all rotations, if I used one of them). I didn’t try
to prune the transformations, since the given tasks did not seem representative
of the tasks needed on the leaderboard.
The transformations stacked very well, even solving several tasks in which I
used other transformations (not available to the model) during hand-solving.

5 Ensembling
In the final model I run 4 different configurations and ensemble the predictions.
I run transformations search depth 3, depth 3 augmented with diagonal flips
(times two diagonal flips), and finally run depth 4 until I run out of time or

2
memory. The best predictions are picked according to the following criteria,
with the top criterion being the most important one:
• Solved the most training samples

• Least depth solution


• Least stacked images in the greedy stacker

6 Tricks
Augmenting my samples with diagonally flipped tasks, was a simple trick which
gave me significantly better score. Preprocessing all samples by remapping
colors according to some heuristics, also worked surprisingly well.
I believe my main advantage over most other competitors was my experience
from competitive programming. It allowed me to quickly and efficiently write
large amounts of image transformations in C++, which let me search through
many more combinations of transformations compared to a python implemen-
tation or an otherwise less optimized solution.

7 Execution time
A natural way to make my approach run faster is to reduce search depth. When
I use the full 9 hours I can run about half the problems at depth 4, while
running at depth 3 is about 20× faster (and takes 20× less memory). During
development I would run at depth 2, which is again about 15× faster than depth
3, while solving about 80% as many tasks on the evaluation set.

8 Code
The implementation is available at [Link]

Common questions

Powered by AI

Efficiency was ensured by implementing the solution in C++ for optimized performance and utilizing a DSL to handle image transformations effectively. He employed parallel execution along with specific tricks like preprocessing samples by remapping colors based on heuristics and augmenting tasks with diagonal flips, significantly improving scores. Additionally, reducing search depth was a strategy to manage run-time and memory within constraints .

Constraints included a 9-hour runtime and 16 GB memory limit. Johan's solution addressed these by using a simple scheduler to optimize resource use, implementing algorithms in C++ for better performance, and reducing search depth to make the solution faster and more memory-efficient. He leveraged heuristics to manage color preprocessing, and carefully selected transformations to fit within these constraints .

To improve robustness, Johan utilized ensembling with four configurations and varied search depths. He also employed diagonal flips and remapped colors to optimize predictions. Through experimentation, he ensured that transformations could solve multiple tasks. His strategy to stack transformations effectively allowed him to adapt to various scenarios beyond those designed .

Incorporating competitive programming principles proved beneficial by enabling efficient algorithm development and rapid problem-solving under constraints. These principles facilitated constructing transformations quickly and effectively, essential for addressing the diverse and novel nature of ARC tasks. The skills gained from competitive contexts allowed Johan to optimize performance, manage large datasets, and create a robust solution .

The main component of his solution was a Domain-Specific Language (DSL) that applies up to four of 142 unary transformations. These transformations were developed after hand-solving 100 training and 100 evaluation tasks, extracting useful functions, and generalizing them by incorporating all rotations, for example. He processed these transformations efficiently in C++ and used a simple scheduler to manage the full 9-hour runtime effectively .

Image transformations formed a crucial part of Johan's ARC solution, allowing the manipulation of data to fit training samples. Key transformations included 'Cut' to split pixels, 'filterCol' to erase all but a specific color, 'colShape' to change pixel colors, 'composeGrowing' for layering images, 'compress' for extracting sub-images, and 'rigid' for rotations and flips. These transformations were hand-crafted and generalized based on problem-solving experiences .

The DSL was pivotal in managing the solution's complexity as it allowed for the modular application of image transformations. With up to 142 transformations based on 42 functions, the DSL facilitated the enumeration and efficient combination of these functions. By reducing duplicates and ordering transformations, the DSL streamlined the solution architecture, allowing for scalable and flexible manipulation .

Johan employed ensembling by running four different configurations, each searching transformations with varying depths. He executed these configurations and then combined predictions based on specific criteria such as solving the most training samples, using solutions with the least depth, and utilizing the least stacked images. This approach was used to select the best predictions and enhance the model’s performance .

The ARC competition format aligned with Johan's strengths because it lacked well-established solutions, allowing him to design an effective approach from scratch. His competitive programming experience enabled the efficient construction and testing of transformations, critical in solving ARC tasks under constraints. This absence of predefined methods encouraged innovation, leveraging his problem-solving and algorithm development skills .

Johan Sokrates Wind used his experience from competitive programming to efficiently write simple algorithms, such as flood fill, dynamic programming, and Huffman coding, which are crucial for the ARC. His background enabled him to quickly write and implement image transformations, which were essential for his solution. The skills gained from larger projects like visual odometry implementation helped him structure his code flexibly, allowing easy addition of new ideas .

You might also like