Hard input constraints:
  • inputs are 3x3
  • inputs contain only 2 colors monocolored: black and another
Hard output constraints:
  • output is 3x input width and height. Suggests that the output is a 3x3 grid based on the input.
    • stronger: if output is split as a 3x3 grid, then each 3x3 block is either black or a copy as input. Which is which?
      • stronger: each pixel of the input determines if block is black or copy (final solution)
  • output contains only two colors: black and another
Input output comparison:
  • input appears pasted on output multiple times: suggests it is being copy pasted
Hard output constraints:
  • output is 3x input width and height: suggests that the output is a 3x3 grid based on the input
    If that is the case, let's try to figure out what is placed on each output grid.
    Notice: each grid element is either blank or the input.
    OK so let's determine what in the input determines each output grid.
    Because input in 3x3 maybe there's a direct mapping.
Hard input constraints:
  • inputs have two colors: green and black
Hard output constraints:
  • output has three colors: black, green and yellow
  • output has same size as input
  • green is copied from input to output
    • output differs from input by making some black pixels yellow. Which pixels are becoming yellow?
Input constraints:
  • inputs are 3x6
Output constraints:
  • outputs are 3x9
TODO: this one is quite challenging.
Output constraints:
  • Input and output have the same size
  • Supposing background is black, input and output contain the same number of objects of each color
    • the lower right part of each object (non-diagonal) does not move
      • the rest of each object outside the lower right part moves by 1 square to the right
Has the following structure:
  • Training Set: 1000 tasks: a variety of difficulty levels, easy to hard, designed to contain all "primitives" needed for eval
  • Public Eval Set: 120 tasks
  • Semi-Private Eval: 120 hard tasks, may have been exposed to limited third-parties eg. via API
  • Private Eval Set: 120 tasks, never exposed to third parties
These section lists common visual primitives that a solver must first extract in order to infer solutions.
Some of these have a lot of prior world content, others less.
Many people have come up with the same idea on the Discord. Some nicely call it DSL.
Implementations:
If a color is inferred to be a background color, it contains no information and should be ignored.
Most problems tend to use black as a background color, but not all of them.
An "object" is a set of points that is understood to be one singular entity.
Contiguity and having the same color are strong indicators that something should be understood as an object.
A rectangular container.
The toplevel viewport is always implicitly understood as a special box.
There are two or more boxes drawn inside the toplevel and sharing boundaries with toplevel.
There are two toplevel boxes, one contains only input, and all output goes to the second one. The second one may also contain some input.
A path is something you obtain by somehow drawing from one point to another, e.g. a line, and then starting another drawing between two points from the end point.
Rectangle is like a box but always fully filled.
A point is a 1-square.
A dotted line is a generalized line that cycles between a color pattern, e.g.:
r r g
would be a line:
r r g r r g r r g
An extra color "transparent" may also be added to not change for that pixel.
There is no unique solution, we just have to optimize something, often the least changed colors.
To the left of the vertical red line, count the number of each color on each row.
Then to the right, on each line draw one square of each color to the left every n columns, starting with a square on the first column to the right of the red line, where n is the count of that color.
Start with the color furthest away from the red line, and then color with colors nearer to the red line. If there's overlap, replace the old color with the new one.
Output:
Input primitives:
Transformations primitives:
  • line drawing
Solution: move pieces to fill the gap on the fat object that crosses the screen. Place objects either on fat object or on other objects placed on the fat object. Anything you add must end in a rectangle.
The rules for this one are not entirely clear with the number of examples.
Also clearly if the goal is to make rectangular towers, then this is an NP-hard optimization problem in general.
Input primitives:
  • same color chunk. Properties: crosses screen.
Transformation primitives:
  • move solid around
  • fills the gap
Solution: vs are guns that shoot diagonal line of their color, when line touches another object, change line color to match that of the object, then bounce on the object and continue going with the new color
Input primitives:
Assumptions:
  • line don't cross each other, it is unclear how to resolve that case
Transformation primitives:
  • draw line
    • draw line and bounce
Transformation primitives:
TODO I can't solve that one.
Output:
Input:
Output:
Input: three or more containers:
Output:
They are moving to 2d discrete AI games.
Although there is merit in that, it is a shame that it just similar to other pre-existing work such as gvgai and many others.
Solutions to these solutions require much more thought to formalize a solution.
Also the solutions are much less unique, finding the actual optimal solution being obviously NP-hard.
These aspects make those games much less elegant than the older ARC-AGI 1 and 2 counterparts.
This section is about unofficial ARC-AGI-like problem sets.
These are interesting from both a:
  • practical point of view, as they provide more training data for potential solvers. If you believe that they are representative that is of course.
  • theoretical point of view, as they might help to highlight missing or excessive presumptions of the official datasets
github.com/neoneye/arc-dataset-collection contains a fantastic collection of such datasets, with visualization at: neoneye.github.io/arc/
By the author of ARC-DSL.
README says:
This repository presents code to procedurally generate examples for the ARC training tasks. For each of the 400 tasks, an example generator is provided.
arxiv.org/html/2404.07353v1 says:
Each generator is a standalone Python function merely making use of the DSL and functions from the random module from the standard library. The median generator consists of 40 lines of code and uses 22 DSL primitive calls and 10 calls to the random module.
Cool!
Original:
https://web.archive.org/web/20250216160803im_/https://github.com/michaelhodel/re-arc/raw/main/00d62c1b_original.png
Generated:
https://web.archive.org/web/20250216160803im_/https://github.com/michaelhodel/re-arc/raw/main/00d62c1b_generated.png

Ancestors (11)

  1. ARC-AGI
  2. AGI test
  3. Artificial general intelligence
  4. AI by capability
  5. Artificial intelligence
  6. Machine learning
  7. Computer
  8. Information technology
  9. Area of technology
  10. Technology
  11. Home

Synonyms (1)

View article source

Discussion (0)

New discussion

There are no discussions about this article yet.

Articles by others on the same topic (0)

There are currently no matching articles.
See all articles in the same topic Create my own version