In Part One I introduced the ARC Prize Challenge.
In Part Two We analyzed a simple Puzzle requiring the Action MOVE.
In Part Three We introduced an advanced PAINT Action and saw how ARCHIE's architecture implicitly supports the IF-THEN-ELSE conditional.
⇨ ?
⇨ ?
This article is not an attempt to catalog all of ARCHIE's specific commands. The goal is to give you an idea of the level of sophistication ARCHIE is capable of utilizing when attempting Abstract Reasoning and Generalization. The selected STROKE examples illustrate support for Object Occlusion and Implied Completeness. ARCHIE does have explicit OBJECTS, Attributes, Actions, and Parameters. It also has a growing (but not infinite) set of implied Concepts.
⇨ ?
This classic ARC Puzzle requires ARCHIE to use an Action different from MOVE or PAINT. Here the Input Objects are single pixels. They transfer to the Output grid statically. ADDED pixels tightly surround the Objects in a pattern similar to a graphic program's STROKE command.
⇨ ?
Here the Grey pixel Objects get a Blue Stroke, and the Green Object gets a Yellow Stroke. Object detection is tricky as the Blue Stokes blend together in the 2nd output Example, and in the first Example, the Yellow Stroke partially OCCLUDES a Blue Stroked Object. In both cases, ARCHIE needs to look past the direct pixel representations to understand the presence of COMPLETED Output Objects.
⇨ ?
This variation challenges ARCHIE with four variations of the STROKE Action. How is STROKE configured to support this? [STROKE,(colors),("Full","Corners","Sides"),(center color)]
Example 1 shows the single-pixel Objects transforming via STROKE like the puzzle above. However, in this "Tough Even for Humans" example, only 2 of the Objects are intact. 4 of the STROKED Objects are only partially visible. Example 2 and 3 are even more challenging to solve as NONE of the Output Objects are completely visible. Only through Abstraction can the intended shapes be discerned and the appropriate STROKE Action determined. But let's look at Example 1 first.
In the first full pass, ARCHIE correctly recognizes the intact Objects and assigns the correct STROKE Action Parameters to them. The 4 other Objects are still listed as [Static] and the [ADDED] pixels are listed below the window view. The way to interpret the Action [STROKE,2.6.8.7,Sides,*] is:
Since there are still [ADDED] lines in the Output Object field, ARCHIE will branch into a second pass, trying to resolve these.
And it does!
Example 1 provided the configuration for Blue, Example 2 for Green, Example 3 for Grey, and Yellow [DELETE]. The hierarchical nature of ARCHIE's decision making process prevents this functionality from becoming a combinatorial explosion. It is not utilizing Randomization, Brute Force, Greedy Algorithms, or other lazy shortcuts to software design. This is the value of Curriculum Training, and it more closely matches the approach a Human problem solver would take.
Anyone spending time with the ARC Puzzle corpus knows that not all examples are simply "Objects against a Background." Identifying Multicolor Objects is one minor shift demonstrated in Part Five. There are other less frequent, but larger conceptual shifts in the corpus. If Objects function as Maps or Puzzle Pieces, for example, that would be a Paradigm Shift. ARCHIE solves these as well. Here are two examples:
⇨ ? 
Using an OBJECT definition of contiguous pixels of the same color, each of these examples have 3 or more objects present, and detecting a uniform transformation across them is confounding. There are no background pixels in this puzzle. Abstracting the OBJECT definition results in a single OBJECT occupying each entire Grid. Comparing single OBJECT to single OBJECT across grids, ARCHIE easily solves the puzzle by applying the Action [MOVE,r180,0,0] to the grid.
⇨ ? 
⇨ ? 
Here the definition of an OBJECT shifts away from Color and Contiguity, to Function. The first grid sizes I created for ARCHIE were 9x9, after seeing this type of "As Below, So Above" paradigm. Here, the Input Object actually functions as a 3x3 MAP, each pixel representing where a copy of the MAP pixels should be placed. It's pretty fun once you know OBJECTS can function as MAPs. Handling MAPs is a specific Action type for ARCHIE and not terribly generalizable. I'm not sure how many children could readily solve this type of puzzle.
⇨ ? 
PART FIVE will describe the Banner puzzle that current AI is unable to solve despite $ millions in resources. This section will also introduce the power of ARCHIE's Compound ACTIONS.