Intel's Ronler Acres Plant

Silicon Forest
If the type is too small, Ctrl+ is your friend

Wednesday, December 16, 2009

Eternity Puzzle, Part 6

I figured out what the problem was with my program. It's a matter of how you look at orientation. If your point of reference moves clockwise, that is the same as the having the reference remain still and the tile turn counter-clockwise. I still haven't fixed the code. I don't seem to have the necessary motivation. But I came up with a new scheme that might lead to a solution. I had great hopes of implementing it, but since that isn't happening, I thought I would write it up and maybe some industrious person could make use of it.

The idea is to start small, but pervasive, and work your way up. Start with making square blocks of four tiles whose adjoining edges match. Start with the first tile and make as many blocks of four as you can. Go to the next tile and repeat. You will have a couple hundred groups of four for each tile.

Next, go through the list and eliminate any duplicates. Now select 64 of the blocks such that each tile is used only once. See if the number of unmatched edges can be arranged so that the counts in each direction come out even. That is, for any one color/pattern, the number of edges facing left should equal the number of edges facing right, and the number of edges facing down should equal the number of edges facing up. If this set meets all these criteria, then you can go on to the next phase.

At this point there are two directions you can go. One is to generate all the possible sets of blocks that meet these criteria. The other is go on to the next phase.

The next phase is to take four of your blocks and see if you can group them into square blocks of 16 tiles. Since we have already established the orientations of the 4 tile blocks, this should be fairly quick to complete, or fail.

When you have reached this point then it might be worthwhile to just see if you can solve the complete puzzle. You only have 16 squares at this point.

The only problem I see is that the number of combinations of 4 tile blocks might be too enormous to winnow down in a timely manner. The other problem is that there are a number of steps where it is necessary to insure that all possibilities are considered. A brute force approach where you only check one tile at a time does not have this weakness.

No comments: