Can we cover the unit square by these rectangles? - MathOverflow most recent 30 from http://mathoverflow.net 2013-05-21T19:37:20Z http://mathoverflow.net/feeds/question/34145 http://www.creativecommons.org/licenses/by-nc/2.5/rdf http://mathoverflow.net/questions/34145/can-we-cover-the-unit-square-by-these-rectangles Can we cover the unit square by these rectangles? Kaveh 2010-08-01T19:48:51Z 2012-06-23T12:37:54Z <p>The following question was a <em>research</em> exercise (i.e. an open problem) in R. Graham, D.E. Knuth, and O. Patashnik, "Concrete Mathematics", 1988, chapter 1.</p> <p>It is easy to show that</p> <p>$$\sum_{1 \leq k } (\frac{1}{k} \times \frac{1}{k+1}) = 1.$$</p> <p>The product $\frac{1}{k} \times \frac{1}{k+1}$ is equal to the area of a $\frac{1}{k}$by$\frac{1}{k+1}$ rectangle. The sum of the areas of these rectangles is equal to 1, which is the ares of a unit square. <strong>Can we use these rectangles to cover a unit square?</strong></p> <blockquote> <p>Is this problem still open? </p> <p>What are the best results we know about this problem (or its relaxations)?</p> </blockquote> http://mathoverflow.net/questions/34145/can-we-cover-the-unit-square-by-these-rectangles/34149#34149 Answer by Andrey Rekalo for Can we cover the unit square by these rectangles? Andrey Rekalo 2010-08-01T20:25:57Z 2012-06-23T12:37:54Z <p>This problem actually goes back to Leo Moser. </p> <p>The best result that I'm aware of is due to D. Jennings, who proved that all the rectangles of size $k^{-1} × (k + 1)^{-1}$, $k = 1, 2, 3 ...$, can be packed into a square of size $(133/132)^2$ (<a href="http://www.sciencedirect.com/science?_ob=ArticleURL&amp;_udi=B6WHS-4CVPWT9-11&amp;_user=273788&amp;_coverDate=11%252F30%252F1994&amp;_rdoc=1&amp;_fmt=high&amp;_orig=search&amp;_sort=d&amp;_docanchor=&amp;view=c&amp;_searchStrId=1417996873&amp;_rerunOrigin=scholar.google&amp;_acct=C000015798&amp;_version=1&amp;_urlVersion=0&amp;_userid=273788&amp;md5=ba98dbefefe2df956b5cc202a80b5324" rel="nofollow">link</a>). </p> <p><strong>Edit 1.</strong> A web search via Google Scholar gave a reference to this <a href="http://www.sciencedirect.com/science?_ob=ArticleURL&amp;_udi=B6V00-3SYPSYH-N&amp;_user=273788&amp;_coverDate=01%252F01%252F1998&amp;_rdoc=1&amp;_fmt=high&amp;_orig=search&amp;_sort=d&amp;_docanchor=&amp;view=c&amp;_rerunOrigin=scholar.google&amp;_acct=C000015798&amp;_version=1&amp;_urlVersion=0&amp;_userid=273788&amp;md5=23e2795d1899d2ca41e5c64252139537" rel="nofollow">article</a> by V. Bálint, which claims that the rectangles can be packed into a square of size $(501/500)^2$.</p> <p><strong>Edit 2.</strong> The state of art of this and related packing problems due to Leo Moser is discussed in Chapter 3 of <a href="http://books.google.co.uk/books?id=cT7TB20y3A8C&amp;printsec=frontcover&amp;dq=Research+Problems+in+Discrete+Geometry&amp;source=bl&amp;ots=ampA5AGiJ3&amp;sig=peuMukAVFcivXibr5W-8q1RWs2A&amp;hl=en&amp;ei=kN1VTIPQNsTKjAfVj4XDBA&amp;sa=X&amp;oi=book_result&amp;ct=result&amp;resnum=6&amp;ved=0CDIQ6AEwBQ#v=onepage&amp;q&amp;f=false" rel="nofollow">"Research Problems in Discrete Geometry"</a> by P.Brass, W. O. J. Moser and J. Pach. The problem was still unsettled as of 2005. </p> http://mathoverflow.net/questions/34145/can-we-cover-the-unit-square-by-these-rectangles/34379#34379 Answer by Derek Jennings for Can we cover the unit square by these rectangles? Derek Jennings 2010-08-03T13:20:57Z 2010-08-03T13:20:57Z <p>It's been a long time since I considered this problem, so prompted by seeing this question I was intrigued to discover more on V. Bálint's bound of $(501/500)^ 2.$</p> <p>A quick search revealed Bálint's paper <a href="http://books.google.co.uk/books?hl=en&amp;lr=&amp;id=SDP05SGOGn0C&amp;oi=fnd&amp;pg=PA17&amp;dq=related%3aUELKCjbtmJ8J%3ascholar.google.com/&amp;ots=CXB2QSCpbb&amp;sig=Ltd4B1ywiI7fb6tUBp3NakeQ5ok#v=onepage&amp;q&amp;f=false" rel="nofollow">A Packing Problem and Geometrical Series</a>. In this article it is only stated that with some patience one can pack the first 499 rectangles into the unit square. However, the main difficulty of the problem is to pack the larger rectangles and so it would have been nice to see a demonstration.</p> <p>Bálint addresses the question in <a href="http://www.sciencedirect.com/science?_ob=ArticleURL&amp;_udi=B6V00-3SYPSYH-N&amp;_user=10&amp;_coverDate=01/01/1998&amp;_rdoc=1&amp;_fmt=high&amp;_orig=search&amp;_sort=d&amp;_docanchor=&amp;view=c&amp;_searchStrId=1419843239&amp;_rerunOrigin=scholar.google&amp;_acct=C000050221&amp;_version=1&amp;_urlVersion=0&amp;_userid=10&amp;md5=de376999fe641676d05e2271fc5d1432" rel="nofollow">Two Packing Problems</a> but I do not have easy access to this and so now I'm concerned that a similar claim, without a demonstration, may have been made in this paper too.</p> <p>Please could someone with access to the paper lay my concern to rest?</p> <p>I would very much like to have confidence in the later bound as its validity makes the problem yet more interesting. Can we get arbitrarily close to 1? I still see no good reason why this should be the case but it's a fascinating possibility that hints at the prospect of something quite deep going on.</p> http://mathoverflow.net/questions/34145/can-we-cover-the-unit-square-by-these-rectangles/38319#38319 Answer by ed-wynn for Can we cover the unit square by these rectangles? ed-wynn 2010-09-10T14:47:43Z 2010-09-10T14:56:54Z <p><p>As a bit of fun, I have written a program that attempts to fit the first n rectangles into the square. (I accept that this is not an obvious route to a proof.) </p><p> Initially, I planned to jumble the rectangles without any strategy, except that I constrained each new rectangle to share a vertex with at least one previous rectangle. Unfortunately, I quickly found that backtracking is extremely time-consuming. In retrospect, this makes sense: if a state is reached where there are only N spaces big enough to accept the next (N+1) rectangles, backtracking will probably need to try all (N!) permutations before deciding to backtrack further. (And this is as it should be, because one of the permutations may free up a corner to allow progress.) So, without strategy, 255 rectangles go in and then there is no more progress for a long time in this algorithm: <a href="http://uploadingit.com/view/ynlvk8l8f6zg1qrm/s6_real_255_touch0.gif" rel="nofollow">Dead end</a> </p><p> So, I added a bit of strategy: try to make as many edge-to-edge joins as possible. With this algorithm, I have reached 40000 (and still going) without any need at all for backtracking. (In fact, it's quite rare to find an exact fit into a gap, where a new rectangle has edge-to-edge contact with three existing rectangles. Therefore, in retrospect, it would probably be roughly as good to insist that new rectangles have two or more edge-to-edge contacts -- which will effectively mean fitting into "corners" where the new rectangle fills the only remaining quadrant at a vertex.) </p><p> Here's an image of the situation after 10000 rectangles: <a href="http://uploadingit.com/view/aa9q1lqgb32qyu6n/s6_real_10000_touch3.gif" rel="nofollow">Maximized_contact</a>. There is a different pattern, arguably just as good, if the first position with 2 edge-to-edge contacts is selected: <a href="http://uploadingit.com/view/3tjukgxvidjq1syb/s6_real_1000_touch2.gif" rel="nofollow">Two_contacts</a> (after 1000 rectangles). This is quicker. </p><p> For the squeamish, look away now: I have been using floating-point arithmetic. With the gcc compiler's somewhat lame "long double", this stores about 20 decimal places. So, I have insisted that an "exact" contact must have coordinates that match to at least 19 decimal places. A "clear" gap or overlap between non-contacts must be at least, say, 10^-14 -- so there are 5 orders of magnitude between "presumably touching" and "presumably separate". You could regard this as having a probabilistic chance of a mistake, and I guess (without justification) the probability might be of order 10^-5. </p><p> If gaps are required to be at least 1e-12, then the algorithm is unsure whether (1/3912 + 1/4124 - 1/4050 - 1/3981) is zero or gap. If gaps are at least 1e-13, the same happens with (1/26981+29981-14201). These are real examples, and it's easy to concoct other situations that would challenge higher precision. (For example, try 1/30234+1/26811-1/28672-1/28172.) So far, no in-between gaps (between 1e-19 and 1e-14) have been encountered. </p><p> I have recently started checking the results using arbitrary-length rational numbers (using the <a href="http://spinning-yarns.org/michael/sw/imath/" rel="nofollow">IMath package</a>). This is slower, of course. The size of the denominator could be excessive (see <a href="http://www.research.att.com/~njas/sequences/A003418" rel="nofollow">A003418</a>), but only 138 base-10 digits were required up to 4800 rectangles. This took about 5 hours on a desktop. The code isn't designed for efficiency, and gets progressively slower in a variety of ways. </p><p> It may seem pointless to press on beyond 1000, or 2000 or whatever, and it probably is. However, there is an exciting crunch point at about 17000: until this point, there has been a clear region of unfilled space, substantially larger than the incoming rectangles. Any rectangle that doesn't fit conveniently elsewhere can go in there. This is quite a luxurious position: you can tell at a glance that deadlock won't be reached in the next few placements. When that space is filled, are the remaining slivers large enough? -- the rectangles aren't small enough that remaining gaps look like wide-open spaces. Initial experience suggests that this crunch is survived, but of course there may be more crunches to come. </p><p> Here are images: <a href="http://uploadingit.com/view/agovlqqiepq2byc6/s6_real_10000_touch3_zoom1.gif" rel="nofollow">Wide open space at 10000</a> and <a href="http://uploadingit.com/view/jogolpnkqz0b9on7/s6_real_15000_touch3_zoom1.gif" rel="nofollow">Impending crunch at 15000</a>, <a href="http://uploadingit.com/view/gh9mmmphjixoos5r/s6_real_17000_touch3_zoom2.gif" rel="nofollow">Crunch at 17000</a> (zoomed in) and <a href="http://uploadingit.com/view/5vpizxxto99fpgbk/s6_real_30000_touch3_zoom2.gif" rel="nofollow">Crunch averted so far, at 30000</a> </p><p> @Kevin Buzzard: I hope this doesn't take the fun out of your interactive applet. I think you're right that a bit of insight comes out of this square-bashing: there is hope that there are enough small rectangles to more or less fill the gaps between medium rectangles, and enough really small rectangles to more or less fill the gaps between small rectangles, and so on. This seems to be the hope, rather than clever arrangements of exact matches. </p><p> I can be specific about the rarity of filling exact matches using this algorithm: 20 three-edge contacts in the first 1000 rectangles, 6 in the next, and 4 in the next. Presumably more could be arranged by thinking ahead. Also, a better algorithm could do a lot more to avoid small gaps (which must be the killer in the end, if there is a killer). </p></p>