Finding a maximal square from a finite set of tiles (approximation) - algorithm

I have a final set of tiles in which every edge can have on of four colors.
The task is to find a maximal possible square build from a given set (finite) of this tiles. Tiles can be rotated.
I need to design 3 algorithms for finding a solution for this task. One complete and two aproximations.
Obviously it is my task for Algorithms class so Im not asking about complete solutions (as this would be unfair) but for some directions.
Im already designed a kind of complete algorithm (using backtracking - search for a square of size sqrt(n) - if it could not be found try finding smaller and so on) but I have no idea how to create aproximation algorithms. I think one will be kind of stupid which will find a good answer only in specific cases just to document that it is not a good aproach but still I need one much faster then backtracking and quite good one.
Also is this problem NP-hard one? My backtracking algorithm is exponential one but it doesnt mean that there cannot be a better one...
EDIT: I have complete algorithm with exponential time, could some one give me some hints how to build some kind of aproximation for this problem with polynomial time or something better then exponential?
EDIT2: I have the idea that this problem can be changed to a problem of reducting a graph to square grid graph ( http://mathworld.wolfram.com/GridGraph.html ). Still there is a problem if the tiles can be arranged in such a way to build a grid, but this could be a good point to start. Are there any, for example, greedy or any other aproximation algorithms for reducting graph to square-grid graph?

Suppose your backtracking algorithm constructs k-by-k squares for increasing values of k.
You can extend the backtracking algorithm with heuristics. So instead of choosing the next tile randomly, choose and attach a tile such that the colors of the free tiles "agree with" those on the square. The big problem is to find the "agreement" heuristics. One possible heuristics is to find the least common color on the free tiles and use it.

Related

Divide an image by grouping similar pixels into rectangles

consider an image like this:
by grouping pixels by color into distinct rectangles, different configurations might be achieved, for example:
the goal is to find one of the best configurations, i.e. a configuration which has the least possible number of rectangles (rectangles sizes are not important).
any idea on how to design an efficient algorithm which is able to solve this problem?
EDIT:
i think the best answer is the one by #dshin, as they proved that this problem is a NP-HARD one so there probably isn't any efficient solution that is able to guarantee an optimal result.
other answers provide reasonable compromises to get an acceptable solution, but that won't always be the optimal one.
Each connected colored region is a rectilinear polygon that can be considered independently, and so your problem amounts to solving the minimum rectangle covering for rectilinear polygons. This is a well-studied problem that finds applications in some fields, like VLSI.
For convex rectilinear polygons, there is an algorithm that finds the optimal solution in polynomial time, described in this 1984 thesis.
The non-convex case is NP-hard (reference), so an efficient optimal solution likely does not exist. But there are several algorithms which produce good empirical results. This 1990 publication describes three separate algorithms, each of which are guaranteed to use at most twice as many rectangles as the optimal solution. This 2016 publication describes an algorithm that uses the common IP + LP relaxation technique, which apparently produces better results in real-life problem instances, although lacking in theoretical guarantees. Unfortunately, both publications are behind paywalls, and I haven't been able to find free resources that describe the algorithms.
If you are just looking for something reasonable, and your problem instances are not pathological in nature, then the algorithms described in other answers are probably good enough.
I don't have a proof but my feeling is a greedy approach should solve this problem:
Start on the upper left (or in whichever corner)
Expand rectangle 1px to the right as long as colors match
Expand rectangle 1px to the bottom as long as all colors in that row match
Line by line and column by column, find the next pixel that is not already part of a square (maybe keep track of visited pixels in a second array) and repeat 2 and 3.
You can switch lines and columns and go up and left or whatever instead and end up with different configurations, but from playing this through in my mind I think the number of rectangles should always be the same.
The idea here is based on the following links: Link 1 and Link 2.
In both the cases, the largest possible rectangle is computed within a given polygon/shape. Check both the above links for details.
We can extend the idea above to the problem at hand.
Steps:
Filter the image by color (say red)
Find the largest possible rectangle in the red region. After doing so mask it.
Repeat to find the next biggest rectangle until all the portions in red have been covered.
Repeat the above for every unique color.
Overview:

Optimization strategies for finding a no re-visit graph traversal path (all vertices)

In an effort to dust off my somewhat rusty programming skills I'm trying to solve this graph traversal problem I ran across.
I want to find a path that visits all coordinates (vertices) on a 10x10 grid. There are some movement restrictions like only being able to move 3 steps in either direction (x+/-3 OR y+/-3) or 2 steps diagonally (x+/-2 AND y+/-2). From what I understand these restrictions don't really matter much since it's still just a graph with vertices and edges and I can model this easily enough in my solution.
I got so far as to being able to solve this problem for a 6x6 grid using a "simple" DFS strategy (at least I think that's what I've produced :). But going bigger than that I run into performance problems since the O(n) of my algorithm is kinda crap. 7x7 takes like 45 mins on my computer so 10x10 is just forget-about-it.
I figured out that a 5x5 grid can always be solved so I guess one viable strat would be to divide the 10x10 into 4x5x5. But that doesn't feel like a proper solution and even tho it would solve grids with sides of multiples of 5 I would still not be able to solve 8x8 and 11x11 etc.
So my question here is about what strategies can be applied to optimize for this particular problem?
Your problem is the Hamiltonian path problem, which is NP-complete for arbitrary graphs. This means there is no known efficient algorithm, so trying to solve this for arbitrary graphs will be fairly fruitless.
Instead, use the fact that you're solving it on a grid. You can simply go row-by-row, turning around at the ends.
If you have a limited set of moves you can do on a grid you can also look at knight's tour literature.

How to tell when the A* algorithm is a good option, and how to choose a good heuristic?

Recently I wrote a solver for the famous "15 puzzle" using the A* algorithm by using a heuristic function based off the sum of the Manhattan distances of the distances for each tile to their destination spots.
This led me to wonder two things:
How do you know when the A* algorithm is even something to use? Unless I came across online tutorials, I would have never guessed that the 15 puzzle could be solved this way.
How do you know which heuristic function to use? At first, for the 15 puzzle, I considered a simple "sum of tiles not in position" heuristic. So if all pieces weren't in their right spots, the heuristic for the 15 puzzle might return 15, whereas 0 would indicate a solved board. But somehow the sum of the distances are better. How does one know, going into it?
If you're exploring a graph to find a path that is in some way "shortest" (the cost doesn't have to be a "distance", but it has to be monotone), you can already use Dijkstra's. Your problem will typically look nothing like path-finding at a first glance though, as in, you're not planning to "travel over a route". It's more abstract than that.
Then if you can use Dijkstra and you have some admissible heuristic (that's the hard part), you can use A*.
An often used technique for finding heuristics is dropping some constraint of your problem. For example, if you can teleport each tile to its destination regardless of whether there's already a tile there, it will take #displacements teleports. So there's the first heuristic. If you have to slide the tiles but they can slide through each other, the cost for each tile is the Manhattan distance to its destination. Then you can look at improving the heuristic, for example the Manhattan distance heuristic obviously ignores that tiles interfere with each other as they move, but there is a simple case where we know where tiles must conflict and use more moves: consider two tiles (pretend there are no other tiles) in the same row and their destinations are also on that row but in order to get there they'd have to pass through each other. They'd have to go around each other, adding two vertical moves. This gives the Linear Conflicts heuristic. Even more interference can be taken into account, for example with pattern databases.

Reverse Rectangle Packing

I have a connected shape that consists of squares put together, e.g. take a squared paper and draw a line along the existing lines that ends at its beginning and does not cross itself.
The goal is now to find an algorithm (not brute-force) that fills this shape with as few, non-overlapping rectangles as possible.
I'm looking for the optimal solution. As can be seen in the images, the naive greedy approach (take the largest rectangle) does not work.
(Optimal)
(Greedy)
My scenario is vertices reduction, but I'm sure there are other use-cases as well.
Note: This problem seems basic, but I was not able to find a solution elsewhere. Also, is this problem NP-hard?
Edit: I just realized that, in my scenario, filling the shape with as few non-overlapping triangles as possible, would give an even better result.
I've spend a lot of time researching this, since I asked the initial question. For the first problem (optimally filling the shape with rectangles), I've written the solution here under the header "Optimal Greedy Meshing":
http://blackflux.wordpress.com/2014/03/01/meshing-in-voxel-engines-part-2/
The complexity is actually better (faster) than for optimally triangulating a polygon without holes. The slowest part is the Hopcroft-Karp algorithm.
Treating the shape as a polygon is also discussed in the linked blog post. Note that I'm also considering holes.
The first problem is harder than the one with triangles; for triangles, see the algorithms in
http://en.wikipedia.org/wiki/Polygon_triangulation
which can do it without any extra vertices.

Cutting Heuristic Solving Algorithm for n-edged polygone

I want to programm a tool that can place objects on a rectangle with the minumum of waste, this problem is also known as the cutting problem.
So i looked around to find some algorithms and i found out there are a few for rectangles but not that much for n-edged polygones.
my first approach was to get a bounding box for the polygone, then run the normal rectangle algorithm. After that you cound slowly try to increase the number of edges but still have only isometric lines (only vertical and horizontal), to approximate the polygone.
I wonder if there is any good algorithm that implement such thing, but is more common than create my own stuff.
the other way ive come up with could be something with two dimensional knapsack and some sorting heuristics that sort the best fitting polygones and try to put them on the rectangle.
But all i come up with has some good detection of special polygones (such as a square or normal rectangle) but does not work on common polygones.

Resources