alejandrodemiquel / arc_kaggle Goto Github PK

Currently, in the main loop, we correct the fixed colors that have been modified by a given operation, reverting the change. Maybe we should extend the corrections: Not only correct the fixecColors, but also restore the colors that are commonChangedInColors and are not in changedOutColors.

In some cases, it would be convenient to convert some samples into several ones, if there is more than one multicolorShape and they all behave independently.

Some examples are:

Separate by shapes: 80,84,101,119,201,229,279,281,282,293,337,381,396,410,412,429,432,455,469,496,497,502,504,513,517,525,528,531,552,599,602,610,611,613,640,650,654,657,673,681,697,729,750,777

Separate by colors: 3,231,339,397,420,427,455,461,470,505,532,537,572,630,701,754,769,780,781

Could be easy to implement maybe? Examples: 616, 619, 632, 666

I am not sure if we already have something in these lines. Add a test to check if the test samples belong to the input samples (in some sense), such as in task 55. Then return trainSample.outMatrix. It is fairly naive, but why not.

In some cases, the background color is not correctly determined. This could be solved by imposing the background color to be the one of the Shape with shape equal to inMatrix.shape.

• Cases in which this approach would solve the issue: 48, 155, 215, 282, 293, 364, 380, 441, 473, 525, 529, 535, 591

Problematic cases:

• Cases with grid with cells with equal shape: 58, 148, 162, 256, 313, 607, 647, 733, 766, 776
• Other grids: 54, 182, 188, 225, 516, 579, 677, 757, 770
• Other cases: 144, 366, 431

Things to be done:

• Implement the cases in which direction is ul, ur, dl, dr, h, v, d1, d2, all in Utils.moveAllShapes.
• Make sure that all the options that make sense are added to Utils.getPossibleOperations.

Happens many times after one of the startOps is executed. In particular with minimize. This wastes a lot of computation time.

File "/kaggle/src/script.py", line 1683, in mapPixels
m[i,j] = inMatrix[pixelMap[i,j]]
IndexError: index 6 is out of bounds for axis 0 with size 3

See task 26 as example

It should be solved, but it isn't because of the initial color change I suspect.

It's possible to do it in a more clever and efficient way.

Send a matrix (of 1s and 0s is you're working mod 2) to a function, and check if a color change happens only if there is a 1 or a 0.

See task 41 as example

After certain kinds of operations, such as changeShapes, it makes complete sense to run tryOperations again right after the operation is executed if all the modified pixels have been modified correctly. See task 337 as example.

I think that theoretically it should be solved, right?

Many tasks contain shapes of different colors. They are clearly Shapes because there is a clear background color.
Specifying the color should not be mandatory when instantiating a Shape.

In some cases, a color has a specific behaviour. However, we don't identify this color as special because it doesn't appear in ALL of the samples. Tasks 532 (pink color doesn't appear in the first training sample) and 748 (blue and pink don't appear in one sample each) are two examples.

Maybe we should be more flexible in deciding which colors are special? For example, allow a color to not appear in one training sample if there are at least 5.

Creating separate issue for this.

"Task 645 doesn't get solved because, after the crop, the background color changes in the outMatrix of trainSamples[2]."

Not sure about what's best here. Options I can think of right now:

• Avoid cropping certain tasks.
• Do the main loop with both, cropping and no cropping (quite time consuming)
• Avoid somehow that the background color doesn't change between input and output if it doesn't make sense

Any other ideas @RodericGuigoCorominas ?

inShapeFactor doesn't need to be a fixed number. It could also be the number of colors present in the input, or the shape of the input squared. Would be nice to find a way to implement this.

To deal with cases like 70 or 116

Should be solved with changeShapes and connectAnyPixels.

Maybe I should add a function that ALWAYS changes from one color to another one if the change is obvious?

This issue targets at tasks that involve evolving lines. Some examples (not all) are tasks 790, 749, 748, 703, 679, 629, 605, 585, 573, 457, 344, 322, 283, 236, 231, 201, 198, 59, 23.

TODOs:

• Add the option 'jump' or 'skip' when encountering a fixed color. The line would just continue its way without coloring the fixed color.
• Add the option 'split'. The line would split in two when encountering an obstacle. See task 790 as example.
• Turn after x steps. See task 749 as example.
• Consider the cases in which the source color is different than the line color. See task 605 as example.
• Add diagonal evolving lines.
• Be color independent, as in task 236.
• Add rules for the borders.
• Consider sources that are not only a pixel.
• Modify direction after turning.
• Switch color. See task 435 as example.

In some cases, the color of a Shape in the input determines the color of other shapes in the output. We should be able to detect these reference shapes, detect which actions they imply, and act accordingly.

Find a way to deal with frames.

• Detect frames: be it made out of a rectangle, two lines or four (or even two) pixels.
• Does the frame determine the output shape?
• Is sameIOShapes, is the outside unchanged? Is the inside unchanged?
• Does the frame only contain one Shape?

To deal with cases like 216

if m.shape[0]>1:
        for i in range(m.shape[0]):
            color = m[i, 0]
            isFrontier = True
            for j in range(m.shape[1]):
                if color != m[i,j]:
                    isFrontier = False
                    break
            if isFrontier:
                frontiers.append(Frontier(color, 'h', i))

This function will not check for horizontal lines if image is a horizontal line only

Tasks like 720 should be solved with this function too.

Task 748, for example, would be solved without recoloring. However, it is not solved. Not sure how to deal with this right now. Opening this issue to drop all new ideas and information about other problematic tasks.

The following tasks have sameIOShapes, and are only modified in the pixels that remain after doing cropAllBackground. Some of them would benefit of doing cropAllBackground to all the input matrices as a first step (like we do in ignoreGrid). Some of them would be even solved I believe.
These are the tasks: 22,84,91,104,131,165,223,245,283,334,341,407,419,422,432,437,445,456,485,497,530,541,547,564,610,611,625,634,640,657,673,678,680,681,682,691,701,702,710,716,722,745,756,758,762,767,773,779,780,792,795,798

Some of them, like 611, 640 or 767 for example, even consist of different blocks that are independent and should be considered separately.

Proposal for new function. Would solve tasks like 13, 120 and many others I think.

See task 653 as example

This function should solve tasks like 303. Activate matrix if a pixel is of a certain color.

Thanks for your contribution! Such nice work on ARC!

However, there is a huge gap between the performance of train/eval and the test. On train/eval, the code can achieve 60%-80% accuracy, while only 20% is achieved on the test reported by Kaggle.

What could possibly account for this difference?

I'm starting this issue to store ideas that are quick and easy to implement and that could have some good potential for solving extra tasks. Feel free to add any ideas that you might have in mind @RodericGuigoCorominas .

• Use pixelwiseAnd/Or/Xor if in the input only consits of Task.Shapes of the same shape
• Use pixelwiseAnd/Or/Xor if in the input only consits of frames of the same shape

This will avoid using LSTM, which is computationally expensive.

Targeted tasks: 175, 331, 459, 594

There should be a method called isSubshape for the class Shape.

Horizontal, vertical or diagonal.
Would solve tasks like 62, 302 or 656.

See tasks 686 and 36 as examples

@RodericGuigoCorominas Do you think that it would make sense to consider a cropManyShapes function to solve the tasks below (or a subset of them)? Do you think that your experience with overlap, crop and replicate could help?

21,45,95,125,158,200,232,237,252,263(?),295,365(?),414,440,475(?),498,523,535(?),558,588,589,622,624(?),652,676,699,759,760, as examples.

See task 647 as example.

See task 249 for example

For tasks like 22 or 161.