Talk:Cut a rectangle: Difference between revisions
Content added Content deleted
| Line 126: | Line 126: | ||
:* Instead of using a two-state matrix (marked/unmarked), how about using a tri-state one (unmarked/side one/side two)? Every time you mark a cell "side one", also mark its diagonal opposite "side two"; while looking for new neighbors, only pick unmarked cells. This way, when you finish N/2 steps, you are garanteed a symmetric solution, no need to throw out asymmetric combinations. |
:* Instead of using a two-state matrix (marked/unmarked), how about using a tri-state one (unmarked/side one/side two)? Every time you mark a cell "side one", also mark its diagonal opposite "side two"; while looking for new neighbors, only pick unmarked cells. This way, when you finish N/2 steps, you are garanteed a symmetric solution, no need to throw out asymmetric combinations. |
||
:* Instead of searching for cells, directly track the division path ("the cut"). The path must go through the center of the grids; it can only go from one grid point to a neighboring one; it can not go through a grid point twice; starting from the center of the grids (a grid point if m and n are both even, middle of an edge if not), extend the path symmetrically, and as soon as the path reaches any edge of the rectangle, a unique solution is found. This should be much more efficient, with the catch that visualizing the result is a little harder because it doesn't directly tell you which side of the cut a cell belongs to. --[[User:Ledrug|Ledrug]] 03:38, 13 October 2011 (UTC) |
:* Instead of searching for cells, directly track the division path ("the cut"). The path must go through the center of the grids; it can only go from one grid point to a neighboring one; it can not go through a grid point twice; starting from the center of the grids (a grid point if m and n are both even, middle of an edge if not), extend the path symmetrically, and as soon as the path reaches any edge of the rectangle, a unique solution is found. This should be much more efficient, with the catch that visualizing the result is a little harder because it doesn't directly tell you which side of the cut a cell belongs to. --[[User:Ledrug|Ledrug]] 03:38, 13 October 2011 (UTC) |
||
::These sound plausible, though they have a few other potential "gotchas". |
|||
::*The tri-state matrix is going to need a larger data structure to represent it, since it will not allow me to use the bit data type (or I could use a pair of bit matrices, but this would be equivalent to testing for symmetrical overlap at every step). |
|||
::*Also, I believe the division path would require significantly more complex logic (since I need to seek the far diagonal and the division path is variable length). This winds up being equivalent to maze generation where we generate all possible mazes -- it only seems simple because these sample rectangles are small. |
|||
::Anyways thank you for the suggestions -- if we are dealing with large rectangles, I believe the win for testing for symmetry at every step would outweigh its additional computational cost. And I do not have to use a tri-state representation for that -- I just need to test that the new bit's reflected position does not overlap an existing bit. --[[User:Rdm|Rdm]] 11:27, 13 October 2011 (UTC) |
|||