<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/atom10full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><feed xmlns="http://www.w3.org/2005/Atom" xmlns:openSearch="http://a9.com/-/spec/opensearch/1.1/" xmlns:georss="http://www.georss.org/georss" xmlns:gd="http://schemas.google.com/g/2005" gd:etag="W/&quot;CkUFSHs5fyp7ImA9WxJVFE8.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173</id><updated>2009-06-30T23:50:19.527-04:00</updated><title>WebDiarios de Motocicleta</title><subtitle type="html">Informatics Weekly, written by Mihai Pătraşcu.</subtitle><link rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/posts/default" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/" /><link rel="next" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default?start-index=26&amp;max-results=25&amp;redirect=false&amp;v=2" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email></author><generator version="7.00" uri="http://www.blogger.com">Blogger</generator><openSearch:totalResults>121</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><link rel="self" href="http://feeds.feedburner.com/WebdiariosDeMotocicleta" type="application/atom+xml" /><entry gd:etag="W/&quot;A08ASXY_fSp7ImA9WxJVEEs.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-973877018630796512</id><published>2009-06-26T21:26:00.002-04:00</published><updated>2009-06-26T22:30:48.845-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-06-26T22:30:48.845-04:00</app:edited><title>The Conceptual Wars</title><content type="html">Scott Aaronson, in his &lt;a href="http://scottaaronson.com/blog/?p=253"&gt;regular&lt;/a&gt; post-FOCS-notification column, has &lt;a href="http://scottaaronson.com/blog/?p=411"&gt;indicated me&lt;/a&gt; as a leader of the Technicians Resistance Army of TCS (a leader, at least, in irășcibility). &lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;As Anup &lt;a href="http://scottaaronson.com/blog/?p=411#comment-35258"&gt;points out&lt;/a&gt;, our guerrilla force shall strive to remain concealed in the shadows of the dark STOC/FOCS committee rooms. But, as an exposed member, I must accept my destiny as a preacher of our movement during the coming conceptual wars.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;My basic plan is to sing the ideas of theoretical computer science from the rooftops&lt;sup&gt; 1&lt;/sup&gt;. I want to convince you that we have a destiny grander than communicating with quantum aliens. I want to remind you of the beauty of the algorithm. I want to tell you mystical prophecies about the depth our field will achieve when it will show, e.g., that max flow needs superlinear time. And, yes, I want to reprehend you for behaving like a bitter fringe mathematician instead of accepting the place of TCS as the New Maths... Or for having such low self-esteem that you will gladly wipe the floors of the Economics department for some attention. And, against all odds, I want to convince you that solving hard problems is more rewarding than inventing easy new ones.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div style="text-align: center;"&gt;***&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Just, please, hold off the war for a few weeks. For now, I am the chair of the Scientific Committee of the CEOI (Central European Olympiad in Informatics). These kids have prepared for years to get here, and we owe them some exciting problems (which will certainly find their way to the blog later).&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;–––––&lt;/div&gt;&lt;div&gt;&lt;sup&gt; 1 &lt;/sup&gt;&lt;span class="Apple-style-span"  style="font-size:small;"&gt;This cool quotation comes, I believe, from Scott's job application. I learned of it in a bar from a friend who was on the job market at the same time as Scott. My friend added "I don't have this [...] in me."&lt;/span&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-973877018630796512?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/973877018630796512/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=973877018630796512" title="5 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/973877018630796512?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/973877018630796512?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/06/conceptual-wars.html" title="The Conceptual Wars" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">5</thr:total></entry><entry gd:etag="W/&quot;CU4GR38-fSp7ImA9WxJXEUg.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-2623500962019070666</id><published>2009-06-04T18:02:00.002-04:00</published><updated>2009-06-04T18:18:46.155-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-06-04T18:18:46.155-04:00</app:edited><title>Conceptual Contributions Conference</title><content type="html">At STOC, there was an announcement of a new conference dedicated to conceptual contributions, titled &lt;a href="http://itcs.tsinghua.edu.cn/ICS2010/"&gt;ICS&lt;/a&gt; (Innovations in Computer Science). Michael &lt;a href="http://mybiasedcoin.blogspot.com/2009/06/ics-conference-what-should-it-be.html"&gt;asks&lt;/a&gt; for more discussion on this conference.&lt;br /&gt;&lt;br /&gt;Personally, I am enthusiastic about ICS. It seems like one of the best ideas in decades for improving the quality of STOC/FOCS.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-2623500962019070666?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/2623500962019070666/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=2623500962019070666" title="9 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/2623500962019070666?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/2623500962019070666?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/06/conceptual-contributions-conference.html" title="Conceptual Contributions Conference" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">9</thr:total></entry><entry gd:etag="W/&quot;D08FRnk_cCp7ImA9WxJREUs.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-3450922974877295410</id><published>2009-05-12T17:38:00.002-04:00</published><updated>2009-05-12T18:03:37.748-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-05-12T18:03:37.748-04:00</app:edited><title>Conference in Romania</title><content type="html">I am on the program committee for &lt;a href="http://tcs.ieat.ro/"&gt;Advances in the Theory of Computing (AITC'09)&lt;/a&gt;, to take place in Timișoara, Romania on September 26-29. The conference is a new, experimental theory track for a larger and more established conference (The 11&lt;sup&gt;th&lt;/sup&gt; International Symposium on Symbolic and Numeric Algorithms for Scientific Computing, &lt;a href="http://synasc09.info.uvt.ro/"&gt;SYNASC'09&lt;/a&gt;).&lt;br /&gt;&lt;br /&gt;The deadline for regular papers is May 30. You know you always wanted to visit Romania, so use the next couple of weeks to wrap up a result and send it in!&lt;br /&gt;&lt;br /&gt;Alternatively, the conference will double up as a workshop (papers in the "presentation track" will not be published in proceedings, allowing you to submit elsewhere). The deadline for such presentations is July 1st. &lt;br /&gt;&lt;br /&gt;So come to discuss the most exciting developments in theory, while enjoying your 1-liter beers with a view of one of the most beautiful Romanian cities.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-3450922974877295410?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/3450922974877295410/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=3450922974877295410" title="8 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/3450922974877295410?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/3450922974877295410?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/05/conference-in-romania.html" title="Conference in Romania" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">8</thr:total></entry><entry gd:etag="W/&quot;DkQMRXs9eyp7ImA9WxJSF0o.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-6730406264148875158</id><published>2009-05-08T03:42:00.004-04:00</published><updated>2009-05-08T05:19:44.563-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-05-08T05:19:44.563-04:00</app:edited><title>Letter Grades</title><content type="html">&lt;div style="text-align: left;"&gt;In the US, final course grades are expressed in letters (the schemes I've seen are A/B/C, and A/A-/B+/B/B-). This leaves one with the interesting task of drawing barriers in between students (a task best performed at 2am the night before moving out of your apartment).&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;I am not comfortable with adding different components of the grade (like the midterm and final), as the average and standard deviation are vastly different. Is there a good statistical approach to this problem, with some convincing theory behind it? (Being at IBM Almaden, I should automatically go for rank aggregation, I guess... But there seems to be a lot of noise in the rank, since there are clusters of people with similar scores on each exam.)&lt;br /&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Fortunately, if you only give one midterm (and assign low weight to the homework), you can plot the results in 2D. Unfortunately, you may end up with something like this:&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_u9iBO1Zjoks/SgP2PbuyinI/AAAAAAAAAjw/rO9X1p1fewk/s1600-h/image.png"&gt;&lt;img src="http://1.bp.blogspot.com/_u9iBO1Zjoks/SgP2PbuyinI/AAAAAAAAAjw/rO9X1p1fewk/s320/image.png" border="0" alt="" id="BLOGGER_PHOTO_ID_5333377128739277426" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 320px; height: 280px; " /&gt;&lt;/a&gt;&lt;/div&gt;&lt;div&gt;Oh well... Everybody knows grades are somewhat random.&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-6730406264148875158?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/6730406264148875158/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=6730406264148875158" title="13 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/6730406264148875158?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/6730406264148875158?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/05/letter-grades.html" title="Letter Grades" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://1.bp.blogspot.com/_u9iBO1Zjoks/SgP2PbuyinI/AAAAAAAAAjw/rO9X1p1fewk/s72-c/image.png" height="72" width="72" /><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">13</thr:total></entry><entry gd:etag="W/&quot;DUUARns-cSp7ImA9WxJSE0U.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-5678697748866388734</id><published>2009-05-03T15:21:00.003-04:00</published><updated>2009-05-03T17:47:27.559-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-05-03T17:47:27.559-04:00</app:edited><title>Complexity Everywhere</title><content type="html">I know that whenever I write about TCS politics on this blog, it ends up bad. For instance, I get a comment such as the following one (left by an anonymous to my last post):&lt;br /&gt;&lt;blockquote&gt;What makes it tough for some of the papers you cite is the view that shaving off log factors is often viewed as much less interesting than larger improvements.&lt;/blockquote&gt;This, of course, makes my latin blood run even hotter, and I cannot help writing follow-up posts (this is the first). If only I could keep my promise of not writing about politics, my life would be so much simpler. (If only I could learn from history... I got to observe my father become a leading figure in Romanian Dermatology a decade before he could get a faculty position — mainly due to his latin blood. He got a faculty position well into his 50s, essentially going straight to department chair after the previous chair retired.)&lt;br /&gt;&lt;br /&gt;So, let's talk about shaving off log factors (a long overdue topic on this blog). As one of my friends once said:&lt;br /&gt;&lt;blockquote&gt;All this talk about shaving off log factors from complexity people, who aren't even capable of &lt;i&gt;shaving on&lt;/i&gt; a log factor into those circuit lower bounds...&lt;/blockquote&gt;There is something very deep in this quote. Complexity theorists have gone way too long without making progress on proving hardness, their &lt;i&gt;raison d'être&lt;/i&gt;. During this time, drawing targets around the few accidental arrows that hit walls became the accepted methodology. For instance, this led to an obsession about the polynomial / non-polynomial difference, where at least we had an accepted conjecture and some techniques for proving something.&lt;br /&gt;&lt;br /&gt;Complexity theory is not about polynomial versus non-polynomial running times. Complexity theory is about looking at computational problems and classifying then "structurally" by their hardness. There are beautiful structures in data structures:&lt;ul&gt;&lt;li&gt;dictionaries take constant time, randomized. (But if we could prove that deterministically, dynamic dictionaries need superconstant time per operation, it would be a very powerful message about the power of randomness — one that computer scientists could understand better than "any randomized algorithm in time n&lt;sup&gt;c&lt;/sup&gt; can be simulated deterministically in time n&lt;sup&gt;10c&lt;/sup&gt; if E requires exponential size circuits.")&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;predecessor search requires log-log time. The lower bound uses direct sum arguments for round elimination in communication complexity, a very "complexity topic." A large class of problems are equivalent to predecessor search, by reductions.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;the hardness of many problems is related to the structure of a binary hierarchy. These have bound of Θ(lg &lt;i&gt;n&lt;/i&gt;) or Θ(lg &lt;i&gt;n&lt;/i&gt; / lglg &lt;i&gt;n&lt;/i&gt;) depending on interesting information-theoretic issues (roughly, can you sketch a subproblem with low entropy?). There are many &lt;a href="http://people.csail.mit.edu/mip/papers/index.html#structures"&gt;nonobvious reductions&lt;/a&gt; between such problems.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;we have a less sharp understanding of problems above the logarithmic barrier, but knowledge is slowly developing. For instance, I have a conjecture about 3-player number-on-forehead games that would imply n&lt;sup&gt;Ω(1)&lt;/sup&gt; for a large class of problems (reductions, again!). [This was in my Dagstuhl 2008 talk; I guess I should write it down at some point.]&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;the last class of problems are the "really hard" ones: high-dimensional problems for which there is a sharp transition between "exponential space and really fast query time" and "linear space and really slow query time." Whether or not there are reductions among these is a question that has preoccupied people for quite a while (you need some gap amplification, a la PCP). Right now, we can only prove optimal bounds for decision trees (via communication complexity), and some weak connections to NP (if SAT requires strongly exponential time, partial match requires weakly exponential space).&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;Ok, perhaps you simply do not care about data structures. That would be short-sighted (faster data structures imply faster algorithms; so you cannot hope for lower bounds for algorithms before proving lower bounds for data structures) — but it is a mistake that I can tolerate.&lt;br /&gt;&lt;br /&gt;Let's look at algorithms:&lt;ul&gt;&lt;li&gt;Some problems take linear time (often in very non-obvious ways).&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;Sorting seems to take super-linear time, and some problems seem to be as fast as sorting. My favorite example: undirected shortest paths takes linear time, but for directed graphs it seems you need sorting. Why?&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;FFT seems to require Θ(&lt;i&gt;n&lt;/i&gt; lg &lt;i&gt;n&lt;/i&gt;) time. I cannot over-emphasize how powerful an interdisciplinary message it would be, if we could prove this. There are related problems: if you can beat the permutation bound in external memory, you can solve FFT in o(&lt;i&gt;n&lt;/i&gt; lg &lt;i&gt;n&lt;/i&gt;). The permutation bound in external memory is, to me, the most promissing attack to circuit lower bounds.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;some problems circle around the Θ(&lt;i&gt;n&lt;/i&gt; sqrt(&lt;i&gt;n&lt;/i&gt;)) bound, for reasons unclear. Examples: flow, shortest paths with negative lengths, min convolution with a mask. But we do have some reductions (bipartite matching is as hard as flow, bidirectionally).&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;some problems circle around the n&lt;sup&gt;2&lt;/sup&gt; bound. Here we do have the beginning of a classification: 3SUM-hard problems. But there are many more things that we cannot classify: edit distance and many other dynamic programs, min convolution (signal processing people thought hard about it), etc.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;some problems have an n*sort(n) upper bound, and are shown to be X+Y-hard. Though the time distinction between n&lt;sup&gt;2&lt;/sup&gt; and n*sort(n) is tiny, the X+Y question is as tantalizing as they get.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;some problems can be solved in n&lt;sup&gt;ω&lt;/sup&gt; by fast matrix multiplication, while others seem to be stuck at n&lt;sup&gt;3&lt;/sup&gt; (all pairs shortest paths, given-weight triangle). But interestingly, this class is related to the n&lt;sup&gt;2&lt;/sup&gt; problems: if 3SUM needs quadratic time, given-weight triangle requires cubic time; and if min-convolution requires quadratic time, APSP requires cubic time.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;what can we say about all those dynamic programs that run in time n&lt;sup&gt;5&lt;/sup&gt; or something like that? To this party, TCS comes empty-handed.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;how about problems in super-polynomial sub-exponential running time? Ignoring this regime is why the misguided "polynomial / non-polynomial" distinction is often confused with the very meaningful "exponential hardness." There is much recent work here in fixed-parameter tractability. One can show, for instance, that k-clique requires n&lt;sup&gt;Ω(k)&lt;/sup&gt; time, or that some problems require 2&lt;sup&gt;Ω(tree-width)&lt;/sup&gt; time.&lt;br /&gt;&lt;br /&gt;And what can we say about k-SUM and all the k-SUM-hard problems (computational geometry in k dimensions)? This is an important illustration of the "curse of dimensionality" in geometry. I can show that if 3SAT takes exponential time, k-SUM takes n&lt;sup&gt;Ω(k)&lt;/sup&gt; time.&lt;br /&gt;&lt;br /&gt;Finally, what can we say about PTAS running times? In my paper with Piotr and Alex, we showed that some geometric problems requires n&lt;sup&gt;Ω~(1/ε^2) &lt;/sup&gt;running time. This has a powerful structural message: the best thing to do is to exhaustive search after a Johnson-Lindenstrauss projection.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;inside exponential running time, there is the little-known work of [Impagliazzo-Paturi] showing, for instance, that sparse-3SAT is as hard as general 3SAT. Much more can be done here.&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;&lt;div&gt;Lest we forget, I should add that we have no idea what the hard distributions might look like for these problems... Average case complexity cannot even talk about superpolynomial running times (a la hidden clique, noisy parity etc). &lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;This is what complexity theory is about. Sometimes, it needs to understand log factors in the running time. Sometimes, it needs to understand log factors in the exponent. Whereever there is some fascinating structure related to computational hardness, there is computational complexity.&lt;div&gt;&lt;br /&gt;&lt;div&gt;While we construct exotic objects based on additive combinatorics and analyze the bias of polynomials, we should not forget that we are engaging in a temporary exercise of drawing a target around an arrow — a great exploration strategy, as long as it doesn't make us forget where we wanted to shoot the arrow in the first place.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;And while complexity theory is too impotent right now to say anything about log factors, it should not spend its time &lt;a href="http://weblog.fortnow.com/2009/01/soda-and-me.html"&gt;poking fun&lt;/a&gt; at more potent disciplines.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-5678697748866388734?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/5678697748866388734/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=5678697748866388734" title="29 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/5678697748866388734?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/5678697748866388734?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/05/complexity-everywhere.html" title="Complexity Everywhere" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">29</thr:total></entry><entry gd:etag="W/&quot;A0MMQHozcSp7ImA9WxJSEkQ.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-5040509270168688036</id><published>2009-05-02T15:02:00.002-04:00</published><updated>2009-05-02T17:24:41.489-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-05-02T17:24:41.489-04:00</app:edited><title>The non-Gödel papers</title><content type="html">As you probably know, I think theory is in a deep crisis: our obsession to turn into philosophy (prividing unappreciated service to disciplines we do not understand), stemming from our deep commitment to become as ignorant and irrelevant as possible inside the CS department; the influx of people who like to pretend we're Mathematics, and have no idea what computation means; the obsession with the "polynomial" versus "non-polynomial" and it's many consequences; etc etc etc. Since I am not inclined to write novels, I have never been able to put all these arguments inside a coherent text.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Fortunately, every once in a while, the ball is raised at the net and I can say something short that expresses my feelings. Richard Lipton &lt;a href="http://rjlipton.wordpress.com/2009/05/01/great-papers-in-theory/"&gt;talks&lt;/a&gt; about the Gödel prize, and some papers that could also have won it. His examples are all in complexity, which is reasonable since he's a complexity theorist. But looking at the &lt;a href="http://en.wikipedia.org/wiki/G%C3%B6del_Prize"&gt;list of winners&lt;/a&gt; on Wikipedia, what it lacks more is algorithms — you know, papers that try to understand how fast some problems can be solved (the thing non-theorists believe we're studying).&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Here is my own "forgotten list," from which I am certain to have forgotten some papers. Please add your favorite examples in the comments — but note that I am deliberately discarding old papers that were inelligible, like splay trees, classic flow algorithms, persistence, etc. &lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;In no particular order:&lt;/div&gt;&lt;div&gt;&lt;ul&gt;&lt;li&gt;[Fredman-Willard] on the fusion tree. This kick-started a major field (integer search) and directly led to at least two dozen follow-up papers in STOC-FOCS-SODA. Candidates for the Gödel Prize do not get any better.&lt;br /&gt;&lt;br /&gt;This paper has passed its eligibility period, unfortunately. Another good candidate in this line of work would be [Thorup] solving undirected shortest paths in O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;) time.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;Karger's papers on mincut, which are very influential on the use of randomization in graph algorithms.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;Clarkson's introduction of randomization to geometry (thanks, Suresh!).&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;Chazelle's series on "Lower Bounds for Orthogonal Range Searching" is a remarkable contribution. However, Chazelle should probably just win the &lt;a href="http://en.wikipedia.org/wiki/Knuth_Prize"&gt;Knuth Prize&lt;/a&gt; since his contributions are too varied (MST, fractional cascading, triangulation, etc).&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;the power of two choices is an influential and popular idea. I'm not sure who should get the award though; as with PCPs, it can perhaps be shared by a couple of papers.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;dynamic graph algorithms are a broad, deep, and popular research topic. [Henzinger-King] and [Holm-de Lichtenberg-Thorup] could win a joint award for polylogarithmic connectivity. These papers basically restarted the whole area and led to maybe 2 dozen publications in STOC-FOCS-SODA. The latter is also a popular data structure to teach, for its basic beauty.&lt;br /&gt;&lt;br /&gt;Another candidate pair for a joint award would be [Demetrescu-Italiano] and [Sankowski], which give remarkable solutions to all-pairs shortest paths and transitive closure.&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Add your own favorite examples in the comments.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;So, am I claiming an anti-algorithmic bias because these papers did not win? No, all sorts of randomness is involved in prizes. I am claiming an anti-algoritmic bias because, in the current environment, it seems such papers are not even viable candidates.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-5040509270168688036?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/5040509270168688036/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=5040509270168688036" title="13 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/5040509270168688036?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/5040509270168688036?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/05/non-godel-papers.html" title="The non-Gödel papers" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">13</thr:total></entry><entry gd:etag="W/&quot;C0cBQn48cSp7ImA9WxJTEU4.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-4746621524387188185</id><published>2009-04-19T04:49:00.000-04:00</published><updated>2009-04-19T04:50:53.079-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-04-19T04:50:53.079-04:00</app:edited><title>Christos a înviat!</title><content type="html">Happy Easter!  Christos a înviat!&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-4746621524387188185?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/4746621524387188185/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=4746621524387188185" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/4746621524387188185?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/4746621524387188185?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/04/christos-inviat.html" title="Christos a înviat!" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total></entry><entry gd:etag="W/&quot;DEcGQ34_fyp7ImA9WxVaF0k.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-1157348939233841103</id><published>2009-04-14T17:06:00.003-04:00</published><updated>2009-04-14T17:53:42.047-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-04-14T17:53:42.047-04:00</app:edited><title>Theory and Practice</title><content type="html">Via David Eppstein, I find out about the &lt;a href="http://www.umiacs.umd.edu/conferences/tmc2009/"&gt;Workshop on Theory and Multicores&lt;/a&gt;. A memorable citation from the call:&lt;blockquote&gt;[...] Indeed, the programs of many mainstream computer science conferences, such as ASPLOS, DAC, ISCA, PLDI and POPL are heavily populated with papers on parallel computing and in particular on many-core computing. In contrast, the recent programs of flagship theory conferences, such as FOCS, SODA and STOC, hardly have any such paper. This low level of activity should be a concern to the theory community, for it is not clear, for example, what validity the theory of algorithms will have if the main model of computation supported by the vendors is allowed to evolve away from any studied by the theory. The low level of current activity in the theory community is not compatible with past involvement of theorists in parallel computing, and to their representation in the technical discourse.&lt;br /&gt;&lt;/blockquote&gt;Which theory community? The one that thinks our machine models are not robust enough to tell the difference between O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt; lg &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;) and O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;sup&gt;5&lt;/sup&gt;)? The one that thinks n&lt;sup&gt;O(1/ε^2)&lt;/sup&gt; is polynomial and even efficient? The one that thinks Amazon should be happy with an O(lg&lt;sup&gt;3&lt;/sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;) approximation for its profit? The one that thinks the coolest conclusions we ever came to are the philosophical implications of interactive proofs and zero knowledge?&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;The theory community will do just fine, thank you very much.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;div&gt;&lt;div&gt;As for "the low level of current activity" being &lt;span class="Apple-style-span" style="font-weight: bold;"&gt;incompatible&lt;/span&gt; "with past involvement of theorists in parallel computing" --- it is exactly the past involvement that led to the current attitude towards parallel computing! Parallel computing is the fabled field where we got burned badly, and the first example people use to argue that theory is still very young. (It usually goes like this: "Imagine an equivalent of Perelman disappearing for 20 years and coming back with an answer to the most burning question about PRAMs from 1985. Who would care now?").&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;It's going to be hard to regain enthusiasm about parallel computing, as timely as the moment may be.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;But at least we learned our lessons. Never again will a hyped-up mob of theorists rush head-on to study a machine model too early. Never will we study a machine model before such computers are even built, and while the practicality of such computers is still debated. We understand that producing a theoretical model too early will have us chasing the wrong rabbits, and that our results might be as relevant as the 5-state 17-symbol universal Turing Machine was in the design of the Pentium.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Alright, enough of this. I should go back to reading about 3-round quantum interactive proofs with entanglement.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-1157348939233841103?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/1157348939233841103/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=1157348939233841103" title="23 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/1157348939233841103?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/1157348939233841103?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/04/theory-and-practice.html" title="Theory and Practice" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">23</thr:total></entry><entry gd:etag="W/&quot;DkQHSX84cCp7ImA9WxVaE0k.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-1854109930913796148</id><published>2009-04-08T17:47:00.005-04:00</published><updated>2009-04-10T02:18:58.138-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-04-10T02:18:58.138-04:00</app:edited><title>Puzzle: Short-hop permutations</title><content type="html">Count the number of permutations of size &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;, such that |π(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;i&lt;/span&gt;) - π(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;i&lt;/span&gt;+1)| ≤ &lt;span class="Apple-style-span" style="font-style: italic;"&gt;k&lt;/span&gt;, for all &lt;span class="Apple-style-span" style="font-style: italic;"&gt;i&lt;/span&gt;. That is, the hop between any two consecutive values must be short.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;I am asking for an algorithm, not a closed formula. (Combinatorialists: is one known?)&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Your algorithm should work fast for values like &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;=10&lt;sup&gt;6&lt;/sup&gt; and &lt;span class="Apple-style-span" style="font-style: italic;"&gt;k&lt;/span&gt;=8. I have not thought hard about supporting larger &lt;span class="Apple-style-span" style="font-style: italic;"&gt;k&lt;/span&gt; (say, &lt;span class="Apple-style-span" style="font-style: italic;"&gt;k&lt;/span&gt; = 20), but I would certainly be interested to hear such a solution if you have one.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;Credits.&lt;/span&gt; This problem was used in a selection contest for the Romanian olympic team. The original author was Marius Andrei. My subjective judgment of its difficulty is "average+" (it was tricky, but I solved it within 10 minutes). YMMV.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-1854109930913796148?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/1854109930913796148/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=1854109930913796148" title="4 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/1854109930913796148?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/1854109930913796148?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/04/puzzle-short-hop-permutations.html" title="Puzzle: Short-hop permutations" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">4</thr:total></entry><entry gd:etag="W/&quot;CUAAQ3kzeip7ImA9WxVaEUo.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-5086993394573451276</id><published>2009-04-08T01:29:00.004-04:00</published><updated>2009-04-08T02:55:42.782-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-04-08T02:55:42.782-04:00</app:edited><title>CC4: One-Way Communication and a Puzzle</title><content type="html">As we will discuss in the next post, for some application it suffices to get lower bounds on the one-way communication complexity -- that is, the case in which a single message is sent, either from Alice to Bob, or from Bob to Alice. The party receiving the message must immediately announce to answer, based on the message and their own input.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Referring to our INDEXING lower bound in &lt;a href="http://infoweekly.blogspot.com/2009/04/cc3-good-bad-ugly.html"&gt;CC3&lt;/a&gt;, we can immediately obtain a one-way lower bound by setting &lt;span class="Apple-style-span" style="font-style: italic;"&gt;a&lt;/span&gt;=0 (one message Bob→Alice) or &lt;span class="Apple-style-span" style="font-style: italic;"&gt;b&lt;/span&gt;=0 (one message Alice→Bob). We conclude that Alice must send Ω(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;) bits in the A→B model, and that Bob must send Ω(lg &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;) in the B→A model. The former case is much more interesting in applications, so when people say "the one way communication complexity of INDEXING," they always mean the Alice→Bob model.&lt;br /&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;One-way communication is often simple to analyze, and we can obtain lower bounds by direct appeal to information theory. Here is a short and simple proof of the INDEXING lower bound:&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold; font-style: italic;"&gt;Lemma.&lt;/span&gt; The one-way communication complexity of INDEXING is Ω(&lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;).&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;Proof. &lt;/span&gt;Assume there exists a protocol in which Alice sends &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;span class="Apple-style-span" style=""&gt;/10&lt;/span&gt; bits, which works with probability (say) 0.99 over the uniform distribution. We use this to construct an encoder for a random vector of &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt; bits. We show that the average length of the encoding is strictly less than&lt;span class="Apple-style-span" style="font-style: italic;"&gt; n&lt;/span&gt;, which is a contradiction because the &lt;a href="http://en.wikipedia.org/wiki/Information_entropy"&gt;entropy&lt;/a&gt; of the random bit string is &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Say we want to encode &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;[1..&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;]. We give Alice the input &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;, and include her message &lt;span class="Apple-style-span" style="font-style: italic;"&gt;M&lt;/span&gt; in the encoding. Then, we specify the set of indices &lt;span class="Apple-style-span" style="font-style: italic;"&gt;i&lt;/span&gt;, such that, if Bob has input &lt;span class="Apple-style-span" style="font-style: italic;"&gt;i&lt;/span&gt; and receives message &lt;span class="Apple-style-span" style="font-style: italic;"&gt;M&lt;/span&gt; from Alice, he will give an incorrect answer to INDEXING. This is the entire encoding.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Claim 1: we can decode &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt; from the encoding. To accomplish this, simmulate the action of Bob for every possible &lt;span class="Apple-style-span" style="font-style: italic;"&gt;i&lt;/span&gt;. For every index in the bad set, &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;[&lt;span class="Apple-style-span" style="font-style: italic;"&gt;i&lt;/span&gt;] is the opposite of what Bob says.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Claim 2: the average size of the encoding is at most 0.85 &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;. The first component (Alice's message) is &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;span class="Apple-style-span" style=""&gt;/10&lt;/span&gt; in size by assumption. The second component has size lg(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt; choose &lt;span class="Apple-style-span" style="font-style: italic;"&gt;k&lt;/span&gt;), where &lt;span class="Apple-style-span" style="font-style: italic;"&gt;k&lt;/span&gt; is the number of bad indices for a particular &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;. How do we analyze the expected size of this component?&lt;/div&gt;&lt;div&gt;&lt;ul&gt;&lt;li&gt;E&lt;sub&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;A&lt;/span&gt;&lt;/sub&gt;[&lt;span class="Apple-style-span" style="font-style: italic; "&gt;k&lt;/span&gt;] = 0.01 &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;. Indeed, for uniformly random &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt; and &lt;span class="Apple-style-span" style="font-style: italic;"&gt;i&lt;/span&gt;, the algorithm works with probability 0.99. So in expectation over &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;, the bad set of indices has size 0.01 &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;.&lt;br /&gt;&lt;/li&gt;&lt;li&gt;By the Markov bound, Pr&lt;sub&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;A&lt;/span&gt;&lt;/sub&gt;[&lt;span class="Apple-style-span" style="font-style: italic; "&gt;k &lt;/span&gt;≤ 0.02 &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;] ≥ 1/2. &lt;/li&gt;&lt;li&gt;When &lt;span class="Apple-style-span" style="font-style: italic; "&gt;k &lt;/span&gt;≤ 0.02 &lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;,  lg(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt; choose &lt;span class="Apple-style-span" style="font-style: italic;"&gt;k&lt;/span&gt;) ≤ &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;/2.&lt;/li&gt;&lt;li&gt;When &lt;span class="Apple-style-span" style="font-style: italic; "&gt;k &lt;/span&gt;≥ 0.02 &lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;,  lg(&lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt; choose &lt;span class="Apple-style-span" style="font-style: italic; "&gt;k&lt;/span&gt;) ≤ &lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;.&lt;/li&gt;&lt;li&gt;Therefore E[lg(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt; choose &lt;span class="Apple-style-span" style="font-style: italic;"&gt;k&lt;/span&gt;)] ≤ 0.75 &lt;span class="Apple-style-span" style="font-style: italic; "&gt;n.&lt;/span&gt;&lt;/li&gt;&lt;/ul&gt;&lt;div&gt;Therefore, the total size of the encoding is 0.85 &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt; in expectation, contradiction.&lt;/div&gt;&lt;div style="text-align: right;"&gt;&lt;span class="Apple-style-span"   style="color: rgb(85, 85, 68);   font-family:tahoma;font-size:24px;"&gt;□&lt;/span&gt;&lt;br /&gt;&lt;/div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;A puzzle.&lt;/span&gt; Since this blog has featured algorithmic puzzles recently, it's time for a lower bound puzzle:&lt;br /&gt;&lt;blockquote&gt;Say Alice and Bob receive two set of &lt;i&gt;n&lt;/i&gt; elements from the universe [&lt;i&gt;n&lt;/i&gt;&lt;sup&gt;2&lt;/sup&gt;]. Show that the one-way randomized communication complexity of set disjointness is Ω(&lt;i&gt;n&lt;/i&gt; lg &lt;i&gt;n&lt;/i&gt;) bits.&lt;br /&gt;&lt;/blockquote&gt;This is the best result possible, since Alice can specify her entire set with O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt; lg &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;) bits, after which Bob knows the answer with no error. &lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;In fact, the O(&lt;i&gt;n&lt;/i&gt; lg &lt;i&gt;n&lt;/i&gt;) complexity holds even for large universes: use a &lt;a href="http://en.wikipedia.org/wiki/Universal_hashing"&gt;universal hash function&lt;/a&gt; from the universe to a range of 100 &lt;i&gt;n&lt;/i&gt;&lt;sup&gt;2&lt;/sup&gt;. The hash functions introduces zero collisions with probability 99%, so it doesn't introduce false positives in the intersection.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;Acknowledgements.&lt;/span&gt; Thanks to &lt;a href="http://www.sfu.ca/~msa99/"&gt;Mert Sağlam&lt;/a&gt; for telling me about this question. As far as I know, the proof is folklore. &lt;a href="http://www.almaden.ibm.com/cs/people/dpwoodru/"&gt;David Woodruff&lt;/a&gt; wrote an email describing this result many years ago.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-5086993394573451276?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/5086993394573451276/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=5086993394573451276" title="4 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/5086993394573451276?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/5086993394573451276?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/04/cc4-one-way-communication-and-puzzle.html" title="CC4: One-Way Communication and a Puzzle" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">4</thr:total></entry><entry gd:etag="W/&quot;DkQFSHw_eip7ImA9WxVaEEg.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-8782972098907906605</id><published>2009-04-06T01:40:00.003-04:00</published><updated>2009-04-06T17:45:19.242-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-04-06T17:45:19.242-04:00</app:edited><title>Puzzle: Cycle Containing Two Nodes</title><content type="html">The following simple puzzle was circulating among Romanian olympiad participants around 1998. It was supposed to be a quick way to tell apart algorithmists from mere programmers.&lt;br /&gt;&lt;blockquote&gt;Given an undirected graph &lt;span class="Apple-style-span" style="font-style: italic;"&gt;G&lt;/span&gt;, and two vertices &lt;span class="Apple-style-span" style="font-style: italic;"&gt;u&lt;/span&gt; and &lt;span class="Apple-style-span" style="font-style: italic;"&gt;v&lt;/span&gt;, find a cycle containing both &lt;span class="Apple-style-span" style="font-style: italic;"&gt;u&lt;/span&gt; and &lt;span class="Apple-style-span" style="font-style: italic;"&gt;v&lt;/span&gt;, or report than none exists. Running time O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;m&lt;/span&gt;).&lt;/blockquote&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;Update: &lt;/span&gt;Simple ideas based on a DFS (like: find one path, find another) do not work. Think of the following graph:&lt;/div&gt;&lt;div&gt;&lt;a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_u9iBO1Zjoks/Sdp2hqf22nI/AAAAAAAAAi4/HudMYCqlNR8/s1600-h/diamond.GIF"&gt;&lt;img src="http://1.bp.blogspot.com/_u9iBO1Zjoks/Sdp2hqf22nI/AAAAAAAAAi4/HudMYCqlNR8/s320/diamond.GIF" border="0" alt="" id="BLOGGER_PHOTO_ID_5321696230407330418" style="display: block; margin-top: 0px; margin-right: auto; margin-bottom: 10px; margin-left: auto; text-align: center; cursor: pointer; width: 151px; height: 150px; " /&gt;&lt;/a&gt;&lt;/div&gt;&lt;div&gt;If you first find the path &lt;span class="Apple-style-span" style="font-style: italic;"&gt;s&lt;/span&gt; → &lt;span class="Apple-style-span" style="font-style: italic;"&gt;a&lt;/span&gt; → &lt;span class="Apple-style-span" style="font-style: italic;"&gt;b&lt;/span&gt; → &lt;span class="Apple-style-span" style="font-style: italic;"&gt;t&lt;/span&gt;, you will not find a second. &lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;The one-line answer is: try to route two units on flow from &lt;span class="Apple-style-span" style="font-style: italic;"&gt;s&lt;/span&gt; to &lt;span class="Apple-style-span" style="font-style: italic;"&gt;t&lt;/span&gt; in the unit-capacity graph (with unit node capacities if you want simple cycles). This is not the same as two DFS searches, because the second DFS is in the residual graph (it can go back on the edges of the first DFS).&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;About the &lt;/span&gt;&lt;a href="http://infoweekly.blogspot.com/2009/03/classic-problem.html"&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;previous puzzle&lt;/span&gt;&lt;/a&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;:&lt;/span&gt; As many people noticed, Alice can guarantee a win or a draw. She computes the sum of the elements on odd positions and the sum on the even positions. Depending on which is higher, she only plays odd positions or only even positions. (Bob has no choice, since the subarrays he's left with always have the ends of the same parity.)&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;But how do you compute the optimal value for Alice? If the sum of even and odd is equal, how can Alice determine whether she can win, or only draw? A simple dynamic program running in O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;sup&gt;2&lt;/sup&gt;) time works. Can you solve it faster?&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-8782972098907906605?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/8782972098907906605/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=8782972098907906605" title="16 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/8782972098907906605?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/8782972098907906605?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/04/puzzle-cycle-containing-two-nodes.html" title="Puzzle: Cycle Containing Two Nodes" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://1.bp.blogspot.com/_u9iBO1Zjoks/Sdp2hqf22nI/AAAAAAAAAi4/HudMYCqlNR8/s72-c/diamond.GIF" height="72" width="72" /><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">16</thr:total></entry><entry gd:etag="W/&quot;DUUEQno-cSp7ImA9WxVbF0k.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-4237096937731014535</id><published>2009-04-03T01:14:00.003-04:00</published><updated>2009-04-03T04:26:43.459-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-04-03T04:26:43.459-04:00</app:edited><title>CC3: the good, the bad, the ugly</title><content type="html">This is the 3rd post in the thread on communication complexity, following Episodes &lt;a href="http://infoweekly.blogspot.com/2008/05/being-rich-i_23.html"&gt;1&lt;/a&gt; and &lt;a href="http://infoweekly.blogspot.com/2009/03/communication-complexity-ii-randomized.html"&gt;2&lt;/a&gt;.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;This post is also &lt;a href="http://people.csail.mit.edu/~mip/docs/blog/cc3.pdf"&gt;available in PDF&lt;/a&gt;.&lt;br /&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;In today's episode, we will prove our first randomized/distributional lower bound. We will consider a problem that appears quite trivial at first sight -- INDEXING, defined as follows:&lt;/div&gt;&lt;div&gt;&lt;ul&gt;&lt;li&gt;Alice receives a bit vector,  &lt;span class="Apple-style-span" style="font-style: italic;"&gt;x&lt;/span&gt; ∈ {0,1}&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;/sup&gt;&lt;/li&gt;&lt;li&gt;Bob receives an index,  &lt;span class="Apple-style-span" style="font-style: italic;"&gt;y&lt;/span&gt; ∈ [&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;]        (note standard notation: [&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;]={1,...,&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;})&lt;/li&gt;&lt;li&gt;their goal is to output x&lt;sub&gt;y&lt;/sub&gt;, i.e. the y-th bit of the vector x.&lt;/li&gt;&lt;/ul&gt;&lt;div&gt;One way to view INDEXING is as the simplest case of &lt;a href="http://infoweekly.blogspot.com/2008/05/being-rich-i_23.html"&gt;lopsided set disjointness&lt;/a&gt;, where Bob's set is of size one: Alice receives the set &lt;span class="Apple-style-span" style="font-style: italic;"&gt;S&lt;/span&gt; = { &lt;span class="Apple-style-span" style="font-style: italic;"&gt;i&lt;/span&gt; | &lt;span class="Apple-style-span" style="font-style: italic;"&gt;x&lt;/span&gt;&lt;sub&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;i &lt;/span&gt;&lt;/sub&gt;=1 }, and Bob receives &lt;span class="Apple-style-span" style="font-style: italic;"&gt;T&lt;/span&gt; = { &lt;span class="Apple-style-span" style="font-style: italic;"&gt;y&lt;/span&gt; }.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;Intuition.&lt;/span&gt; What trade-off should we expect between Alice's communication &lt;span class="Apple-style-span" style="font-style: italic;"&gt;a&lt;/span&gt;, and Bob's communication &lt;span class="Apple-style-span" style="font-style: italic;"&gt;b&lt;/span&gt;? Clearly, the problem can be solved by [a=1, b=lg &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;] and by [a=n, b=1]. &lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;In between these two extremes, the best use of &lt;span class="Apple-style-span" style="font-style: italic;"&gt;b&lt;/span&gt; seems to be for Bob to send &lt;span class="Apple-style-span" style="font-style: italic;"&gt;b&lt;/span&gt; bits of his index. Alice now knows the index to be in a set of &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;/2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;b&lt;/span&gt;&lt;/sup&gt; possibilities. She can simply send all her bits at these positions, using communication &lt;span class="Apple-style-span" style="font-style: italic;"&gt;a&lt;/span&gt; = &lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;/2&lt;sup&gt;&lt;i&gt;b&lt;/i&gt;&lt;/sup&gt;. Finally, Bob announces the answer with one more bit.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;We thus showed the upper bound: &lt;span class="Apple-style-span" style="font-style: italic;"&gt;a&lt;/span&gt; ≤ &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;/2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;b&lt;/span&gt;-1&lt;/sup&gt;. It should be fairly intutive that this is also a tight lower bound (up to constants). Indeed, no matter what Bob communicates, his index will be uncertain in a set of &lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;/2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;b&lt;/span&gt;&lt;/sup&gt; possibilities (on average). If Alice sends less than &lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;/2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;b&lt;/span&gt;&lt;span class="Apple-style-span" style=""&gt;+1&lt;/span&gt;&lt;/sup&gt; bits of information, at least half of the possible index positions will not have a specified answer based on Alice's message. In other words, the protocol fails to determine the answer with constant probability (i.e. makes constant error).&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;&lt;br /&gt;&lt;/span&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;Distributions.&lt;/span&gt; Before proving a distributional lower bound, we must find the distribution that makes the problem hard. From the intuition above, it should be clear that the right distributions are uniform, both for Alice's vector and for Bob's index.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;Rectangles. &lt;/span&gt;We are in the situation of &lt;span class="Apple-style-span" style="font-style: italic;"&gt;product distributions&lt;/span&gt;: the inputs of Alice and Bob are independent. This is a very good situation to be in, if you remember the main take-home lesson from &lt;a href="http://infoweekly.blogspot.com/2008/05/being-rich-i_23.html"&gt;Episode 1&lt;/a&gt;: rectangles. Remember that some fixed communication transcript is realized in a combinatorial rectangle &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt; x &lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;, where &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt; is a subset of Alice's possible inputs, and &lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt; a subset of Bob's possible inputs. The main ideas of a deterministic proof were:&lt;/div&gt;&lt;div&gt;&lt;ul&gt;&lt;li&gt;little communication from Alice means &lt;span class="Apple-style-span" style="font-style: italic; "&gt;A&lt;/span&gt; is large;&lt;/li&gt;&lt;li&gt;little communication from Bob means that &lt;span class="Apple-style-span" style="font-style: italic; "&gt;B&lt;/span&gt; is large;&lt;/li&gt;&lt;li&gt;but the rectangle must be monochromatic (the answers must be fixed, since the communication is over)&lt;/li&gt;&lt;li&gt;if &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt; and &lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt; are large, you must have both yes-instances and no-instances.&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;&lt;/div&gt;&lt;div&gt;For a product distribution, we will perform essentially the same analysis, given that the densities μ(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;) and μ(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;) can be measured independently. The only difference will be that the rectangle is not monochromatic, but almost monochromatic. Indeed, if the protocol may make some errors, the answer need not be fixed in the rectangle. But it must happen that one answer (yes or no) is much more frequent -- otherwise the error is large.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;The first three steps of the analysis are formalized in the following randomized richness lemma, from the classic paper of [Miltersen, Nissan, Safra, Wigderson STOC'95]:&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;Lemma.&lt;/span&gt; (randomized richness)  Say Alice and Bob compute a function &lt;span class="Apple-style-span" style="font-style: italic;"&gt;f &lt;/span&gt;: &lt;span class="Apple-style-span" style="font-style: italic;"&gt;X&lt;/span&gt;x&lt;span class="Apple-style-span" style="font-style: italic;"&gt;Y&lt;/span&gt; -&gt; {0,1} on a product distribution over &lt;span class="Apple-style-span" style="font-style: italic;"&gt;X&lt;/span&gt;x&lt;span class="Apple-style-span" style="font-style: italic;"&gt;Y&lt;/span&gt;. Assuming that:&lt;/div&gt;&lt;div&gt;&lt;ul&gt;&lt;li&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;f&lt;/span&gt; is dense, in the sense that E[ &lt;span class="Apple-style-span" style="font-style: italic;"&gt;f&lt;/span&gt;(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;x&lt;/span&gt;,&lt;span class="Apple-style-span" style="font-style: italic;"&gt;y&lt;/span&gt;) ] ≥ &lt;span class="Apple-style-span" style="font-style: italic;"&gt;α&lt;/span&gt; ≥ 1/5.&lt;/li&gt;&lt;li&gt;the distributional error is at most &lt;span class="Apple-style-span" style="font-style: italic;"&gt;ε&lt;/span&gt;.&lt;/li&gt;&lt;li&gt;Alice communicates &lt;span class="Apple-style-span" style="font-style: italic;"&gt;a&lt;/span&gt; bits, and Bob &lt;span class="Apple-style-span" style="font-style: italic;"&gt;b&lt;/span&gt; bits.&lt;/li&gt;&lt;/ul&gt;&lt;div&gt;Then, there exists a rectangle &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;x&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt; (&lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;⊂&lt;span class="Apple-style-span" style="font-style: italic;"&gt;X&lt;/span&gt;, &lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;⊂&lt;span class="Apple-style-span" style="font-style: italic;"&gt;Y&lt;/span&gt;) satisfying:&lt;/div&gt;&lt;div&gt;&lt;ul&gt;&lt;li&gt;Alice's side is large: μ(&lt;span class="Apple-style-span" style="font-style: italic; "&gt;A&lt;/span&gt;) ≥ 2&lt;sup&gt;-O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;a&lt;/span&gt;)&lt;/sup&gt;;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;Bob's side is large: μ(&lt;span class="Apple-style-span" style=""&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;&lt;/span&gt;) ≥ 2&lt;sup&gt;-O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;a&lt;/span&gt;+&lt;span class="Apple-style-span" style="font-style: italic;"&gt;b&lt;/span&gt;)&lt;/sup&gt;;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;the rectangle is almost monochromatic: E [ &lt;span class="Apple-style-span" style="font-style: italic;"&gt;f&lt;/span&gt;(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;x&lt;/span&gt;,&lt;span class="Apple-style-span" style="font-style: italic;"&gt;y&lt;/span&gt;) | &lt;span class="Apple-style-span" style="font-style: italic;"&gt;x&lt;/span&gt;∈&lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;, &lt;span class="Apple-style-span" style="font-style: italic;"&gt;y&lt;/span&gt;∈&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt; ] ≥ 1- O(&lt;span class="Apple-style-span" style=""&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;ε&lt;/span&gt;&lt;/span&gt;).&lt;/li&gt;&lt;/ul&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;&lt;span class="Apple-style-span" style="font-weight: normal;"&gt;Proof:&lt;/span&gt;&lt;span class="Apple-style-span" style="font-weight: normal;"&gt;&lt;span class="Apple-style-span" style="font-style: normal;"&gt; Though the statement is very intuitive, t&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span class="Apple-style-span" style="font-weight: normal;"&gt;he proof is actually non-obvious. The obvious approach, which fails, would be some induction on the bits of communication: fix more bits of the communication, making sure the rectangle doesn't decrease too much, and the error doesn't increase too much in the remaining rectangle.&lt;/span&gt;&lt;/span&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;The elegant idea is to use the deterministic richness lemma. Let &lt;span class="Apple-style-span" style="font-style: italic;"&gt;F&lt;/span&gt; be the output of the protocol (what Alice and Bob answer). We know that &lt;span class="Apple-style-span" style="font-style: italic;"&gt;f&lt;/span&gt; and &lt;span class="Apple-style-span" style="font-style: italic;"&gt;F&lt;/span&gt; coincide on 1-&lt;span class="Apple-style-span" style="font-style: italic;"&gt;ε&lt;/span&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt; &lt;/span&gt;of the inputs. By definition, the protocol computes &lt;span class="Apple-style-span" style="font-style: italic;"&gt;F&lt;/span&gt; deterministically with no error (duh!). It is also clear that &lt;span class="Apple-style-span" style="font-style: italic;"&gt;F &lt;/span&gt;is rich, because it is dense E[&lt;span class="Apple-style-span" style="font-style: italic;"&gt;F&lt;/span&gt;] ≥ &lt;span class="Apple-style-span" style="font-style: italic;"&gt;α&lt;/span&gt;-&lt;span class="Apple-style-span" style="font-style: italic; "&gt;ε.&lt;/span&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;So apply the deterministic richness lemma from Episode 1. We get a large rectangle of &lt;span class="Apple-style-span" style="font-style: italic;"&gt;F&lt;/span&gt; in which the answer is one. But how do we know that &lt;span class="Apple-style-span" style="font-style: italic;"&gt;f&lt;/span&gt; is mostly one in the rectangle? It is true that &lt;span class="Apple-style-span" style="font-style: italic;"&gt;F&lt;/span&gt; and &lt;span class="Apple-style-span" style="font-style: italic;"&gt;f&lt;/span&gt; differ on only &lt;span class="Apple-style-span" style="font-style: italic;"&gt;ε&lt;/span&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt; &lt;/span&gt;of the inputs, but that &lt;span class="Apple-style-span" style="font-style: italic; "&gt;ε&lt;/span&gt; might include this entire rectangle that we chose! (Note: the rectangle size is ~ 2&lt;sup&gt;-a &lt;/sup&gt;x 2&lt;sup&gt;-b&lt;/sup&gt;, so much much smaller than some constant &lt;span class="Apple-style-span" style="font-style: italic; "&gt;ε&lt;/span&gt;. It could all be filled with errors.)&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;We were too quick to apply richness on &lt;span class="Apple-style-span" style="font-style: italic;"&gt;F&lt;/span&gt;. Now define &lt;span class="Apple-style-span" style="font-style: italic;"&gt;G&lt;/span&gt;, a cleaned-up version of &lt;span class="Apple-style-span" style="font-style: italic;"&gt;F&lt;/span&gt;. Consider some transcript of the protocol, leading to a rectangle &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;x&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;. If the answer is zero, let &lt;span class="Apple-style-span" style="font-style: italic;"&gt;G&lt;/span&gt;=0 on &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;x&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;. If the answer is one, but the error inside this rectangle is more than 10 &lt;span class="Apple-style-span" style="font-style: italic; "&gt;ε&lt;/span&gt;, also let &lt;span class="Apple-style-span" style="font-style: italic; "&gt;G&lt;/span&gt;=0. Otherwise, let &lt;span class="Apple-style-span" style="font-style: italic; "&gt;G&lt;/span&gt;=1 on the rectangle.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;How much of the truth table gets zeroed out because of excessive error (above 10 &lt;span class="Apple-style-span" style="font-style: italic;"&gt;ε&lt;/span&gt;)? Well, the overall average error is &lt;span class="Apple-style-span" style="font-style: italic; "&gt;ε&lt;/span&gt;, so we can apply a Markov bound to it: the mass of all rectangles in which the error exceeds 10 &lt;span class="Apple-style-span" style="font-style: italic; "&gt;ε &lt;/span&gt;is at most 1/10.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Thus, &lt;span class="Apple-style-span" style="font-style: italic;"&gt;G&lt;/span&gt; is also fairly dense: E[&lt;span class="Apple-style-span" style="font-style: italic;"&gt;G&lt;/span&gt;] &lt;span class="Apple-style-span" style="font-style: italic; "&gt;&lt;span class="Apple-style-span" style="font-style: normal; "&gt;≥ E[&lt;span class="Apple-style-span" style="font-style: italic; "&gt;F&lt;/span&gt;] - 1/10 ≥  &lt;span class="Apple-style-span" style="font-style: italic; "&gt;α - &lt;/span&gt;&lt;span class="Apple-style-span" style=""&gt;(1/&lt;/span&gt;&lt;span class="Apple-style-span" style=""&gt;10)&lt;/span&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt; &lt;/span&gt;- &lt;span class="Apple-style-span" style="font-style: italic; "&gt;ε &lt;span class="Apple-style-span" style="font-style: normal; "&gt;≥ 1/10 - &lt;span class="Apple-style-span" style="font-style: italic; "&gt;ε&lt;/span&gt;. Thus, &lt;/span&gt;G&lt;span class="Apple-style-span" style="font-style: normal; "&gt; is rich, and we can find a bit rectangle in which it is identically one. But in that rectangle, E[&lt;/span&gt;&lt;span class="Apple-style-span" style=""&gt;f&lt;/span&gt;&lt;span class="Apple-style-span" style="font-style: normal; "&gt;] ≥ 1 - 10 &lt;span class="Apple-style-span" style="font-style: italic; "&gt;ε&lt;/span&gt; by construction of &lt;/span&gt;G&lt;span class="Apple-style-span" style="font-style: normal; "&gt;.&lt;br /&gt;&lt;div style="text-align: right;"&gt;&lt;span class="Apple-style-span"   style="color: rgb(85, 85, 68);   font-family:tahoma;font-size:24px;"&gt;□&lt;/span&gt;&lt;br /&gt;&lt;/div&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;/div&gt;&lt;br /&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;The good, the bad, the ugly. &lt;/span&gt;It remains to prove that in &lt;span class="Apple-style-span" style="font-style: italic;"&gt;any&lt;/span&gt; large rectangle, the fraction of zeros must be non-negligible (it may not be almost all ones). This part is, of course, problem specific, and we shall do it here for INDEXING. &lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Unfortunately, these proofs are somewhat technical. They typically apply a number of "pruning" steps on the rectangle. An example of pruning on the space of rectangles was seen above: we zeroed out all rectangles that had more than 10 &lt;span class="Apple-style-span" style="font-style: italic; "&gt;ε &lt;span class="Apple-style-span" style="font-style: normal;"&gt;error.&lt;/span&gt;&lt;span class="Apple-style-span" style="font-style: normal; "&gt; In these proofs, we throw out rows and columns we don't like for various reasons. One usually makes many funny definitions, talking about "good rows", "bad rows", "ugly columns", etc.&lt;/span&gt;&lt;/span&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;While looking at such proofs, it is important to remember the information-theoretical intuition behind them. After you understand &lt;span class="Apple-style-span" style="font-style: italic;"&gt;why&lt;/span&gt; the statement is true (handwaving about the information of this and the entropy of that), you can deal with these technicalities on the night before the STOC/FOCS deadline.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Here is how the proof proceeds for INDEXING:&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;Lemma:&lt;/span&gt;&lt;/span&gt; Consider any &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt; ⊂ {0,1}&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;&lt;/sup&gt; and B ⊂ [&lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;] such that |A| ≥ 2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;&lt;span class="Apple-style-span" style=""&gt;+1&lt;/span&gt;&lt;/sup&gt; /&lt;span class="Apple-style-span"  style=" ;font-size:13px;"&gt;&lt;span class="Apple-style-span"  style=" ;font-size:16px;"&gt; 2&lt;sup&gt;|&lt;i&gt;B&lt;/i&gt;|/2&lt;/sup&gt;. Then E&lt;sub&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;A&lt;/span&gt;,&lt;span class="Apple-style-span" style="font-style: italic; "&gt;B &lt;/span&gt;&lt;/sub&gt;[&lt;span class="Apple-style-span" style="font-style: italic; "&gt;f&lt;/span&gt;(&lt;span class="Apple-style-span" style="font-style: italic; "&gt;x&lt;/span&gt;,&lt;span class="Apple-style-span" style="font-style: italic; "&gt;y&lt;/span&gt;)] ≥ 0.95.&lt;/span&gt;&lt;/span&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;Proof: &lt;/span&gt;Assume for contradiction that Pr&lt;sub&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;,&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B &lt;/span&gt;&lt;/sub&gt;[&lt;span class="Apple-style-span" style="font-style: italic;"&gt;f&lt;/span&gt;(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;x&lt;/span&gt;,&lt;span class="Apple-style-span" style="font-style: italic;"&gt;y&lt;/span&gt;) = 0] ≤ 1/20. Let an ugly row be a row &lt;span class="Apple-style-span" style="font-style: italic;"&gt;x&lt;/span&gt;∈&lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt; such that Pr&lt;sub&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B &lt;/span&gt;&lt;/sub&gt;[&lt;span class="Apple-style-span" style="font-style: italic;"&gt;f&lt;/span&gt;(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;x&lt;/span&gt;,&lt;span class="Apple-style-span" style="font-style: italic;"&gt;y&lt;/span&gt;) = 0] &gt; 1/10. At most half of the rows are ugly by the Markov bound. Discard all ugly rows, obtaining &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;'⊂&lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;, with |&lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;'| ≥ |&lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;|/2.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;For every remaining &lt;span class="Apple-style-span" style="font-style: italic; "&gt;x&lt;/span&gt;∈&lt;span class="Apple-style-span" style="font-style: italic; "&gt;A'&lt;span class="Apple-style-span" style="font-style: normal; "&gt;, we have &lt;span class="Apple-style-span" style="font-style: italic;"&gt;x&lt;/span&gt;&lt;sub&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;y&lt;/span&gt;&lt;/sub&gt;=0 for at least 0.9 |&lt;/span&gt;&lt;span class="Apple-style-span" style=""&gt;B&lt;/span&gt;&lt;span class="Apple-style-span" style="font-style: normal; "&gt;| indices from &lt;/span&gt;&lt;span class="Apple-style-span" style=""&gt;B&lt;/span&gt;&lt;span class="Apple-style-span" style="font-style: normal; "&gt;  (this is the definition of &lt;/span&gt;f&lt;span class="Apple-style-span" style="font-style: normal; "&gt;). Call these good indices. &lt;/span&gt;&lt;/span&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;There are (|&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;|  &lt;span class="Apple-style-span" style="font-style: italic;"&gt;choose&lt;/span&gt;  0.9|&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;|) = (|&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;|  &lt;span class="Apple-style-span" style="font-style: italic;"&gt;choose&lt;/span&gt;  0.1|&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;|) choices for the good indices. For every set of good indices, there are at most 2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;n &lt;/span&gt;- 0.9|&lt;span class="Apple-style-span" style="font-style: italic; "&gt;B&lt;/span&gt;|&lt;/sup&gt; vectors &lt;span class="Apple-style-span" style="font-style: italic;"&gt;x&lt;/span&gt; which are zero on the good indices. Thus:&lt;/div&gt;&lt;blockquote&gt;|&lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;'|  ≤  (|&lt;span class="Apple-style-span" style="font-style: italic; "&gt;B&lt;/span&gt;|  &lt;span class="Apple-style-span" style="font-style: italic; "&gt;choose&lt;/span&gt;  0.1|&lt;span class="Apple-style-span" style="font-style: italic; "&gt;B&lt;/span&gt;|) 2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;n &lt;/span&gt;- 0.9|&lt;span class="Apple-style-span" style="font-style: italic; "&gt;B&lt;/span&gt;|&lt;/sup&gt;  ≤  2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;&lt;/sup&gt; 2&lt;sup&gt;O(0.1 |&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;| lg 10)&lt;/sup&gt; / 2&lt;sup&gt;0.9|&lt;span class="Apple-style-span" style="font-style: italic; "&gt;B&lt;/span&gt;| &lt;/sup&gt;  = 2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;&lt;/sup&gt; / 2&lt;sup&gt;0.9|&lt;span class="Apple-style-span" style="font-style: italic; "&gt;B&lt;/span&gt;|-O(0.1 |&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;| lg 10)&lt;/sup&gt;&lt;/blockquote&gt;This is at most 2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic; "&gt;n&lt;/span&gt;&lt;/sup&gt; / 2&lt;sup&gt;0.5|&lt;i&gt;B&lt;/i&gt;|&lt;/sup&gt; , at least for a sufficiently small value of 1/10 (I never care to remember the constants in the binomial inequalities). We have reached a contradiction with the lemma's guarantee that &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt; is large.&lt;br /&gt;&lt;div style="text-align: right;"&gt;&lt;span class="Apple-style-span"   style="color: rgb(85, 85, 68);   font-family:tahoma;font-size:24px;"&gt;□&lt;/span&gt;&lt;br /&gt;&lt;/div&gt;Combine this with the richness lemma with an error &lt;span class="Apple-style-span" style="font-style: italic; "&gt;ε&lt;/span&gt;=0.05&lt;span class="Apple-style-span" style="font-style: italic; "&gt;. &lt;/span&gt;We have |&lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;|≈2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;-&lt;span class="Apple-style-span" style="font-style: italic;"&gt;a&lt;/span&gt;&lt;/sup&gt; and |&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;|≈&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;/2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;b&lt;/span&gt;&lt;/sup&gt;, so it must be the case that &lt;span class="Apple-style-span" style="font-style: italic;"&gt;a&lt;/span&gt; = Ω(|&lt;span class="Apple-style-span" style="font-style: italic;"&gt;B&lt;/span&gt;|) ≥ &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;/2&lt;sup&gt;O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;b&lt;/span&gt;)&lt;/sup&gt;. We have obtained a tight lower bound.&lt;/div&gt;&lt;/div&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-4237096937731014535?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/4237096937731014535/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=4237096937731014535" title="6 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/4237096937731014535?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/4237096937731014535?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/04/cc3-good-bad-ugly.html" title="CC3: the good, the bad, the ugly" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">6</thr:total></entry><entry gd:etag="W/&quot;C0ACSXo5eCp7ImA9WxVbFkk.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-8338249686479722317</id><published>2009-04-01T22:26:00.003-04:00</published><updated>2009-04-01T23:09:28.420-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-04-01T23:09:28.420-04:00</app:edited><title>Matching in Regular Bipartite Graphs</title><content type="html">It is well known that &lt;span class="Apple-style-span" style="font-style: italic;"&gt;d&lt;/span&gt;-regular bipartite graphs have a perfect matching. Applying this iteratively, it even follows that such graphs can be decomposed into the union of &lt;span class="Apple-style-span" style="font-style: italic;"&gt;d&lt;/span&gt; perfect matchings. (The existence of a matching follows from &lt;a href="http://en.wikipedia.org/wiki/Marriage_theorem#Graph_theory"&gt;Hall's theorem&lt;/a&gt;, which is probably beaten into students during any combinatorics course.)&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;But how easy is it to find a perfect matching in a &lt;span class="Apple-style-span" style="font-style: italic;"&gt;d-&lt;/span&gt;regular bipartite graph? The following classic gem finds a matching in O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;m&lt;/span&gt;) time --- but, oddly enough, it assumes &lt;span class="Apple-style-span" style="font-style: italic;"&gt;d&lt;/span&gt; is a power of two!&lt;/div&gt;&lt;blockquote&gt;Find an Eulerian circuit of the graph in O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;m&lt;/span&gt;) time, which exists for any even &lt;span class="Apple-style-span" style="font-style: italic;"&gt;d&lt;/span&gt;. Now throw out the 2nd, 4th, 6th, etc edges of the circuit. You are left with a graph that is (&lt;span class="Apple-style-span" style="font-style: italic; "&gt;d&lt;/span&gt;/2)-regular. Recurse to find a matching.&lt;/blockquote&gt;Why do you get a regular graph when you throw out all edges on even positions? Think about it: the edges of the circuit go back and forth between the two parties of the graph. For any vertex &lt;span class="Apple-style-span" style="font-style: italic;"&gt;v&lt;/span&gt;, its &lt;span class="Apple-style-span" style="font-style: italic;"&gt;d&lt;/span&gt; incident edges are grouped into &lt;span class="Apple-style-span" style="font-style: italic;"&gt;d&lt;/span&gt;/2 pairs of consecutive edges. One edge of such a pair appears on an odd position in the circuit, and one on an even position.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;This algorithm is due to Gabow and Kariv [STOC'78]. By contrast, obtaining a linear-time algorithm for &lt;span class="Apple-style-span" style="font-style: italic;"&gt;d&lt;/span&gt; not a power of two took until 2001 [Cole-Ost-Schirra]. In SODA'09, [Goel-Kapralov-Khanna] achieved sublinear algorithms for &lt;span class="Apple-style-span" style="font-style: italic;"&gt;d&lt;/span&gt; greater than sqrt(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;). The idea is that matchings are so frequent that you can still find one (with care) in a random sample of the graph. &lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;My interest is not so much with the sublinear complexity, but more with matching in general bipartite graphs (not regular). After you see this beautiful algorithm for matching in&lt;span class="Apple-style-span" style="font-style: italic;"&gt; &lt;/span&gt;regular graphs, it is hard not to feel a bit optimistic that general bipartite matching may also be solvable in O(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;m&lt;/span&gt;) time.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-8338249686479722317?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/8338249686479722317/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=8338249686479722317" title="1 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/8338249686479722317?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/8338249686479722317?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/04/matching-in-regular-bipartite-graphs.html" title="Matching in Regular Bipartite Graphs" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">1</thr:total></entry><entry gd:etag="W/&quot;AkcBQHo_fyp7ImA9WxVbEUU.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-6157470378495383941</id><published>2009-03-26T18:05:00.001-04:00</published><updated>2009-03-27T17:07:31.447-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-03-27T17:07:31.447-04:00</app:edited><title>A Classic Problem</title><content type="html">&lt;div&gt;Consider a doubly-ended queue with 1000 elements. Alice and Bob take turns to remove an element from either end of the queue. The player who removes a larger sum wins.&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Who wins the game?&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;This problem appeared in &lt;a href="http://en.wikipedia.org/wiki/International_Olympiad_in_Informatics"&gt;IOI&lt;/a&gt; 1996 in Hungary, but it's a well-known puzzle by now.&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-6157470378495383941?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/6157470378495383941/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=6157470378495383941" title="13 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/6157470378495383941?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/6157470378495383941?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/03/classic-problem.html" title="A Classic Problem" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">13</thr:total></entry><entry gd:etag="W/&quot;A0MFRncyfip7ImA9WxVbEEQ.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-6475715275437127317</id><published>2009-03-25T23:52:00.003-04:00</published><updated>2009-03-26T16:30:17.996-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-03-26T16:30:17.996-04:00</app:edited><title>Communication Complexity (II): Randomized, Distributional</title><content type="html">&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;Prelude:&lt;/span&gt; A while back I posted an &lt;a href="http://infoweekly.blogspot.com/2008/05/being-rich-i_23.html"&gt;introduction to communication complexity&lt;/a&gt;, in which I showed how to obtain deterministic lower bounds by analyzing monochromatic rectangles. That post is also &lt;a href="http://people.csail.mit.edu/~mip/docs/blog/cc1.pdf"&gt;available in PDF&lt;/a&gt; if you want to review it.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;I will continue with a series of posts giving a "practical introduction" to communication complexity. This will hopefully be a good reference to whoever wants to work in the area. I will ignore as much theory as possible (I find the theory of communication complexity to be quite dry compared to the applications), and take you straight to proving interesting bounds.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;Episode 2. &lt;span class="Apple-style-span" style="font-weight: normal; "&gt;This episode will set up the theory of randomized communication. There are two common extensions beyond deterministic protocols:&lt;/span&gt;&lt;/span&gt;&lt;/div&gt;&lt;dl&gt;&lt;dt&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;randomized complexity:&lt;/span&gt;&lt;br /&gt;&lt;/dt&gt;&lt;dd&gt;The protocol tosses some coins to determine its actions. The communication complexity is fixed independent of the coins. For &lt;i&gt;any&lt;/i&gt; input, the protocol gives a correct answer with probability 2/3 over the coin tosses. This probability can be amplified to any 1-ε, by running O(lg(1/ε)) independent repetitions in parallel, and taking the majority answer.&lt;br /&gt;&lt;br /&gt;&lt;/dd&gt;&lt;dt&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;distributional complexity:&lt;/span&gt;&lt;br /&gt;&lt;/dt&gt;&lt;dd&gt;A distribution &lt;i&gt;D&lt;/i&gt; is specified over the input pairs (x,y), where x is Alice's input, and y is Bob's. The protocol uses some fixed communication complexity, and it gives a correct answer with probability 1-ε over &lt;i&gt;D&lt;/i&gt;. Note that amplification is generally impossible (two independent copies behave identically when run on the same input).&lt;br /&gt;&lt;/dd&gt;&lt;/dl&gt;The case of randomized complexity further splits into two subcases:&lt;dl&gt;&lt;dt&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;public coins:&lt;/span&gt;&lt;br /&gt;&lt;/dt&gt;&lt;dd&gt;The coin tosses are observed by both Alice and Bob.&lt;br /&gt;&lt;/dd&gt;&lt;dd&gt;&lt;br /&gt;&lt;/dd&gt;&lt;dt&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;private coins:&lt;/span&gt;&lt;br /&gt;&lt;/dt&gt;&lt;dd&gt;Each player tosses his own coins privately. They may, of course, communicate the outcomes if they wish. The players trust each other fully, so privacy only makes life more difficult.&lt;br /&gt;&lt;/dd&gt;&lt;/dl&gt;&lt;b&gt;Cannonical example: Equality.&lt;/b&gt; Let Alice and Bob receive two &lt;i&gt;n&lt;/i&gt;-bit vectors x,y ∈ {0,1}&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;/sup&gt;. Their goal is to determine whether x=y. The complexity of this function by each measure is:&lt;ul&gt;&lt;li&gt;Deterministically, the total communication must be Ω(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;), so the players cannot do anything nontrivial. Oddly, this does not follow by richness, as the lower bound is episode 1 (the equality function is only [2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;/sup&gt;,1]-rich). Nonetheless, it can be deduced elementary, as follows.&lt;br /&gt;&lt;br /&gt;We claim that any 1-rectangle cannot be nontrivial (i.e. have more than one cell). If the sides of the rectangle are {x&lt;sub&gt;1&lt;/sub&gt;, x&lt;sub&gt;2&lt;/sub&gt;, ...} and { y&lt;sub&gt;1&lt;/sub&gt;, ...}, then x&lt;sub&gt;1&lt;/sub&gt; = y&lt;sub&gt;1&lt;/sub&gt;, x&lt;sub&gt;2&lt;/sub&gt; = y&lt;sub&gt;1&lt;/sub&gt;, but x&lt;sub&gt;1&lt;/sub&gt; and x&lt;sub&gt;2&lt;/sub&gt; were distinct. &lt;br /&gt;&lt;br /&gt;On the other hand, there are 2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;/sup&gt; cells with a value of one (the diagonal of the matrix). So there must be Ω(2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;/sup&gt;) different rectangles, which can only be obtained by communication Ω(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;).&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;The public coin complexity is O(1). Choose a hash function &lt;span class="Apple-style-span" style="font-style: italic;"&gt;h&lt;/span&gt;:{0,1}&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;/sup&gt; -&gt;  [100] by public coins. Then Alice can communicate &lt;span class="Apple-style-span" style="font-style: italic;"&gt;h&lt;/span&gt;(x), and Bob says yes iff &lt;span class="Apple-style-span" style="font-style: italic;"&gt;h&lt;/span&gt;(x)=&lt;span class="Apple-style-span" style="font-style: italic;"&gt;h&lt;/span&gt;(y). The error probability is 1/100 if &lt;span class="Apple-style-span" style="font-style: italic;"&gt;h&lt;/span&gt; comes from a universal family.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;The private coin complexity is Θ(lg &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;). For the upper bound, Alice chooses a hash function, and communicates both the hash function and &lt;span class="Apple-style-span" style="font-style: italic;"&gt;h&lt;/span&gt;(x). The hash function takes O(lg &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;) bits to communicate (if you know stuff about universal hash functions, the optimal description size grows like loglog of the universe, which in this case is 2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;/sup&gt;).&lt;br /&gt;&lt;br /&gt;The lower bound is not important.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;The distributional communication complexity is only defined if we specify some distributions. For instance, if &lt;i&gt;D&lt;/i&gt; chooses x and y uniformly and independently, a protocol with zero communication works with probability 1 - 1/2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;/sup&gt;. Indeed, Pr[x=y] = 1/2&lt;sup&gt;&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;/sup&gt;, so you may just always answer "no."&lt;/li&gt;&lt;/ul&gt;&lt;b&gt;Some theory.&lt;/b&gt; You can spend some time investigating the relations between these complexity measures, but personally I find this to be dry theory. Here are a few basic factoids you should know.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Lemma 1.&lt;/b&gt; Public coin complexity ≤ Private coins complexity ≤ Public coins complexity + O(lg &lt;i&gt;n&lt;/i&gt;), where &lt;i&gt;n&lt;/i&gt; is the size of the inputs.&lt;br /&gt;&lt;br /&gt;&lt;i&gt;Proof:&lt;/i&gt; This result may seem surprising at first -- Alice and Bob may toss many public coins and use them in a nontrivial way. How can they simmulate this with private coins and just O(lg &lt;i&gt;n&lt;/i&gt;) extra bits of communication?&lt;br /&gt;&lt;br /&gt;In fact, however, the proof is pretty standard in the land of derandomization. The main idea is that you can sample from the space of coin tosses, and understand the behavior just on the sample. Say you sample 100&lt;i&gt;n&lt;/i&gt; strings of random coin tosses. On some input (x,y), the average error probability on the sample is roughly equal to the average error over the true random coins, with probability 1 - 2&lt;sup&gt;-Ω(100 &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;)&lt;/sup&gt; over the random sample. &lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;But there are only 2&lt;sup&gt;2&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;/sup&gt; possible inputs. Thus, there exists a sample which simultaneously works for all inputs (for a large enough value of 100). The protocol may restrict itself to the sample without loss of generality. Then Alice, can pick one of the sample strings by private coins, and communicate the choice with lg(100&lt;i&gt;n&lt;/i&gt;) bits. &lt;span style="font-size:+2;"&gt;&lt;/span&gt;&lt;/div&gt;&lt;div&gt;&lt;div style="text-align: right;"&gt;&lt;span class="Apple-style-span"  style=" ;font-size:24px;"&gt;□&lt;/span&gt;&lt;br /&gt;&lt;/div&gt;&lt;br /&gt;This lemma shows that the gap that we saw in Equality is the maximum possible. The take-away message is that we almost never worry about private-coin complexity, since this restriction changes the complexity so little. When people say "randomized protocol" they almost always mean "public-coin randomized protocol."&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Lemma 2.&lt;/b&gt; Say some problem has a randomized (public-coin) protocol with error probability ε. Then, for any distribution &lt;i&gt;D&lt;/i&gt;, there exists a protocol with distributional error ε.&lt;br /&gt;&lt;br /&gt;&lt;i&gt;Proof. &lt;/i&gt;Let e(x,y)=1 iff the protocol makes an error on inputs x,y. The randomized protocol gives (∀) x,y: E&lt;sub&gt;coins&lt;/sub&gt;[e(x,y)] ≤ε.&lt;br /&gt;&lt;br /&gt;Since every term is bounded, so is the mean: E&lt;sub&gt;(x,y)~&lt;i&gt;D&lt;/i&gt;&lt;/sub&gt;[ E&lt;sub&gt;coins&lt;/sub&gt; [e(x,y)] ] ≤ε.&lt;br /&gt;&lt;br /&gt;But then we can switch the expectations: E&lt;sub&gt;coins&lt;/sub&gt; [ E&lt;sub&gt;(x,y)~&lt;i&gt;D&lt;/i&gt;&lt;/sub&gt; [e(x,y)] ] ≤ε.&lt;br /&gt;&lt;br /&gt;Finally, there exists a setting not exceeding the mean: (∃) coins: E&lt;sub&gt;(x,y)~&lt;i&gt;D&lt;/i&gt;&lt;/sub&gt;[e(x,y)] ≤ε. Having fixed the public coins, the protocol is deterministic.&lt;br /&gt;&lt;br /&gt;Observe that the protocol depends on the distribution &lt;span class="Apple-style-span" style="font-style: italic;"&gt;D&lt;/span&gt;, because the coins are fixed after seeing the distribution, and they're built into the protocol. &lt;span style="font-size:+2;"&gt;&lt;/span&gt;&lt;/div&gt;&lt;div&gt;&lt;div style="text-align: right;"&gt;&lt;span class="Apple-style-span"  style=" ;font-size:24px;"&gt;□&lt;/span&gt;&lt;br /&gt;&lt;/div&gt;&lt;br /&gt;So what does this mean in practice? Just like randomized algorithms are more natural for upper bounds, distributional analyses are more natural in lower bounds. A natural lower bound starts by proposing a distribution &lt;i&gt;D&lt;/i&gt; on the inputs that makes the problem hard. Then, it proves that no protocol can work well on that distribution, implying a distributional lower bound. This is the strongest statement of the lower bound.&lt;br /&gt;&lt;br /&gt;However, as an added bonus, the lower bound implies that no randomized protocol can solve the problem any better. If you think about it, this is obvious: any randomized algorithm can be made deterministic by picking its best set of coins (the coins minimizing error on the hard distribution).&lt;br /&gt;&lt;br /&gt;In principle, it might be possible to show randomized lower bounds directly, without also showing distributional lower bounds. This would be somewhat odd, because it would mean you are showing a lower bound, but you cannot tell us how to choose hard inputs (then why &lt;span class="Apple-style-span" style="font-style: italic;"&gt;is &lt;/span&gt;the problem hard?). Currently, all known randomized lower bounds also give distributional lower bounds.&lt;br /&gt;&lt;br /&gt;The above lemma is sometimes called "the easy direction of Yao's lemma." I oppose the terminology, since it's sily to be giving credit for kindergarden observations. The real "Yao's Lemma" (or the hard direction thereof) is the following:&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Lemma 3. &lt;/b&gt;Assume that for &lt;i&gt;any D&lt;/i&gt;, there exists a protocol with distributional error ε. Then, there exists a randomized protocol with error ε.&lt;br /&gt;&lt;br /&gt;This tells us that trying to find a hard distribution always makes sense. If there exists no distribution that makes the problem hard, it must be that it's actually easy (for randomized algorithms). This is an interesting philosophical statement ("you can always find a hard distribution"), but of course, it is never used in practice.&lt;br /&gt;&lt;br /&gt;The proof is based on the &lt;a href="http://en.wikipedia.org/wiki/Minimax"&gt;von Neumann's minimax theorem&lt;/a&gt; (something you might learn about in economics and game theory). The proof is not important for communication lower bounds, though the minimax principle is something well worth understanding.&lt;br /&gt;&lt;br /&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-6475715275437127317?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/6475715275437127317/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=6475715275437127317" title="4 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/6475715275437127317?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/6475715275437127317?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/03/communication-complexity-ii-randomized.html" title="Communication Complexity (II): Randomized, Distributional" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">4</thr:total></entry><entry gd:etag="W/&quot;C0QBSXc9eSp7ImA9WxVUF0Q.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-7892472369425881336</id><published>2009-03-22T23:53:00.002-04:00</published><updated>2009-03-23T02:55:58.961-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-03-23T02:55:58.961-04:00</app:edited><title>Blogs, research, being social</title><content type="html">&lt;a href="http://en.wikipedia.org/wiki/Richard_J._Lipton"&gt;Richard Lipton&lt;/a&gt; has a new &lt;a href="http://rjlipton.wordpress.com/"&gt;blog&lt;/a&gt;. &lt;a href="http://www.cs.huji.ac.il/~noam/"&gt;Noam Nisan&lt;/a&gt; has a new &lt;a href="http://agtb.wordpress.com/"&gt;blog&lt;/a&gt;.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Does TCS have too many blogs for its own sake? No doubt about that. My Google Reader list of blogs has long ago been downgraded from STOC/FOCS status ("should be aware of") to SODA status ("occasionally you can see interesting things").&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;This partially explains why I haven't been writing much. What should I write on? Maybe I should describe results in my area. But I never learned anything about graph drawing from &lt;a href="http://11011110.livejournal.com/"&gt;David Eppstein&lt;/a&gt;; for me graphs are means, not ends. &lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;I never learned any cryptography from &lt;a href="http://lucatrevisan.wordpress.com/"&gt;Luca.&lt;/a&gt; The really basic problems in cryptography are basic complexity questions -- I already know them, and have no clue how to attack them. The cryptographic side of crypto... well, they can deal with it themselves. I'm only interested enough to hear about it when it's done. [NB: Luca's rare posts about Italian research are cool though -- I use them to argue that research in Romania sucks not because we are emerging from 50 years of comunism, but because we &lt;a href="http://upload.wikimedia.org/wikipedia/commons/a/a8/Map-Romance_Language_World.png"&gt;descend from Rome&lt;/a&gt;. How many researchers from those countries who never worked in the US can you name?]&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;I now understand why online courseware can never replace physical courses: in a physical course, the professor has to waste quite a few hours of his day preparing and teaching. For the student, this sacrifice should (in principle) mean that the stuff is important enough. What would be an equivalent online mechanism that could extract an equivalent sacrifice? Maybe I should pledge $10 to a charity for each person that reads one of my technical blog posts carefully.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;On the other hand, maybe I should write non-technical blog posts trying to influence the community. But I never became convinced that I should include experiments&lt;sup&gt;1&lt;/sup&gt; in my papers. And neither did "the community:" if you ever read comments on Michael's somewhat puritan &lt;a href="http://mybiasedcoin.blogspot.com/"&gt;blog&lt;/a&gt;, you have undoubtedly noticed that he mostly gets comments from people who agree with him, and is usually ignored by theory die-hards.&lt;/div&gt;&lt;blockquote&gt;&lt;sup&gt;1&lt;/sup&gt; If you really must know, I find that algorithm engineering is a craft in itself (which I have been lucky enough to practice in my non-TCS life).  Asking for experiments is like saying you are only interested in papers that completely close a problem.&lt;/blockquote&gt;The obvious issue is the one of sacrifice that I mention above. If you want to convince me of something, let's grab a beer and I'll listen. Proselytizing on the web is too cheap.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;div&gt;Well, then, maybe I should not care too much about content, and should write general observations about life, the universe, and everything (a la &lt;a href="http://weblog.fortnow.com/"&gt;Lance&lt;/a&gt;, &lt;a href="http://www.scottaaronson.com/blog/"&gt;Scott&lt;/a&gt;). The main problem is that we already know the &lt;a href="http://en.wikipedia.org/wiki/Notable_phrases_from_The_Hitchhiker's_Guide_to_the_Galaxy#The_number_42"&gt;answer&lt;/a&gt;. &lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;For as long as I can remember, I have been trying to understand society through mathematics, computer science, economics, mechanism design, etc. If you have a &lt;a href="http://en.wikipedia.org/wiki/%C5%A2uic%C4%83"&gt;țuică&lt;/a&gt; with me, you run a risk of hearing my theories of what the continuum hypothesis really means, what undecidability really means, why the world is the way it is, what the role of research is, how to change this or that aspect of society, and so on. But I do have enough drinks with my friends, and I am left with zero motivation to blog about such things. Online mental exercises are wasted on me.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Which brings me to my next point... The social aspect of research was already bad enough. I grew up going to computer contests, where you were either good enough to win, or not good enough (for instance, in my first year of high school, I missed qualifying for the &lt;a href="http://en.wikipedia.org/wiki/International_Olympiad_in_Informatics"&gt;IOI&lt;/a&gt; by 2 points out of 900, which I found fair enough, if somewhat random). Ideally, research positions should also be handed out by a &lt;a href="http://en.wikipedia.org/wiki/Doctor_of_Philosophy"&gt;5-year contest&lt;/a&gt; for solving hard problems, not by who can draw the biggest target around his arrow.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;The social aspects of the research world may inescapable. But on blogs, hype travels much faster, and waves grow into tsunamis. Noam &lt;a href="http://agtb.wordpress.com/2009/03/20/the-attention-economy-for-scientific-work/"&gt;talks&lt;/a&gt; about the impact of blogs on highlighting results. For all our talk about theoretical depth, our work is already too shallow, if you ask me. I'd hate it if research turned into a Facebook contest for popularity. (NB: This discussion is unrelated to &lt;a href="http://www.cs.toronto.edu/~mbraverm/"&gt;Mark Braverman&lt;/a&gt;'s recent result, which did get quite a few blog posts.)&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Maybe it's time to think about some problems.&lt;/div&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-7892472369425881336?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/7892472369425881336/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=7892472369425881336" title="7 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/7892472369425881336?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/7892472369425881336?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/03/blogs-research-being-social.html" title="Blogs, research, being social" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">7</thr:total></entry><entry gd:etag="W/&quot;C08CR3c8fSp7ImA9WxVUFUo.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-8913136367311716146</id><published>2009-03-20T00:24:00.003-04:00</published><updated>2009-03-20T13:57:46.975-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-03-20T13:57:46.975-04:00</app:edited><title>The LSD Proof</title><content type="html">&lt;div&gt;From my colleagues among Israeli faculty, I hear strange tales about dealing with people who want to be your PhD students. It seems so many students are enthusiastic about doing a PhD (with theory faculty!), that hazing them becomes a good idea. As the stories go, you should tell your candidate students "Go read this paper, and come back once you've understood it."&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;The trick, of course, lies in your choice of the paper. If you ever want to do this to somebody who dreams of working in communication complexity, you might try this &lt;a href="http://people.csail.mit.edu/mip/papers/structures/lsd.pdf"&gt;lower bound for lopsided set disjointness&lt;/a&gt;. The proof is straightforward to me, but it is fairly long and diverse, throwing all the tricks in the book at this problem. If you want to work in communication complexity, it makes sense to first reach the level where the proof is straightforward to you.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;The story of set disjointness stretches back to the dawn of communication complexity. An optimal deterministic lower bound is easy to prove (see my &lt;a href="http://infoweekly.blogspot.com/2008/05/being-rich-i_23.html"&gt;earlier post&lt;/a&gt;). From what I understand, in the late 80's, proving a randomized lower bound was a major problem. The issue is that you cannot use independent distributions for Alice's and Bob's inputs, since two random sets will intersect with overwhelming probability. &lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;A randomized lower bound was obtained in 1992 by [Kalyanasundaram, Schnitger] and by [Razborov]. The technique was explained in an information-theory view by [Bar-Yossef, Jayram, Kumar, Sivakumar], who also found new interesting &lt;a href="http://www.almaden.ibm.com/cs/people/jayram/papers/andor.ps"&gt;applications&lt;/a&gt;.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;The basic idea is to consider a distribution in which the two sets never intersect. Let the universe be split into &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt; blocks. For each block, we will either choose Bob's element publicly, or choose Alice's element publicly. The other player gets a private random input that is different from the public choice, making the sets disjoint. Under this distribution, the blocks are independent. Thus, if the protocol communicates o(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;) bits in total, I can find a block about which it communicates o(1) bits of information. I will now alter the distribution, making it independent on that block alone. The protocol is still the same, so it will have large error because it cannot spot the difference.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;In STOC'95, [Miltersen, Nisan, Safra, Wigderson] introduced asymmetric communication complexity (in which Alice and Bob have inputs of significantly different sizes), and showed how asymmetric lower bounds imply interesting data structure lower bounds. They proved an optimal deterministic lower bounds for asymmetric set disjointness, and left the randomized case as an "interesting" open problem. I suspect, however, that they simply did not have the time or motivation to work out how the previous techniques applied in the asymmetric case.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;In my FOCS'06 &lt;a href="http://people.csail.mit.edu/mip/papers/index.html#eps2n"&gt;paper&lt;/a&gt; with Alex Andoni and Piotr Indyk, we showed the first exciting application of lopsided set disjointness (LSD) to data structures: it implied that data structures with O(1) query time cannot solve (1+ε)-approximate nearest neighbor with less than n^Ω(1/ε&lt;sup&gt;2&lt;/sup&gt;) space. This application only required a weaker version of an LSD lower bound, which could be proved with independent inputs given to Alice and Bob.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;The really exciting development was my FOCS'08 &lt;a href="http://people.csail.mit.edu/mip/papers/index.html#structures"&gt;paper&lt;/a&gt;, which showed that many interesting lower bounds could be obtained by just the right reductions from LSD. At this stage, I needed the optimal LSD lower bound --- so I just had to sit down and claim that the proof would appear in the journal version.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Ridden by guilt (and reminders from &lt;a href="http://compgeom.cs.uiuc.edu/~jeffe/"&gt;Jeff&lt;/a&gt;, acting as editor of the special issue), I had to finally write down the proof. Once you really, really understand the old symmetric technique, and you're confortable with the standard tricks from communication lower bounds, this proof is not too exciting. I'm glad to be done with it.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-8913136367311716146?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/8913136367311716146/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=8913136367311716146" title="0 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/8913136367311716146?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/8913136367311716146?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/03/lsd-proof.html" title="The LSD Proof" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">0</thr:total></entry><entry gd:etag="W/&quot;CUcFSH85fyp7ImA9WxVUEkk.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-8163701754913469211</id><published>2009-03-16T18:26:00.002-04:00</published><updated>2009-03-16T18:36:59.127-04:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-03-16T18:36:59.127-04:00</app:edited><title>Midterm</title><content type="html">As you know, I am teaching Computability and Complexity at Berkeley. Here is the &lt;a href="http://inst.eecs.berkeley.edu/~cs172/sp09/midterm.pdf"&gt;midterm&lt;/a&gt; I gave today. It may be fun for my younger readers to look through it. Leave comments.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Regarding problem 3: I believe nobody should get a CS degree without being able to reason about grammars, precedence, associativity etc. This is far more important that knowing pushdown automata, the pumping lemma or anything like that.  &lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Problems 4 and 7 are typical interview puzzles. Unfortunately, not too many people recognized problem 7 as a disguise for the streaming problem of finding a majority element. I should have asked for Socrates to use only O(n) debates.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Problem 8 is actually hard. Even if you have an intuitive idea why Inca Machines cannot recognize more than regular languages, you need to find a couple of tricks to make it a formal proof.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-8163701754913469211?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/8163701754913469211/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=8163701754913469211" title="10 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/8163701754913469211?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/8163701754913469211?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/03/midterm.html" title="Midterm" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">10</thr:total></entry><entry gd:etag="W/&quot;DU8FRXc4eyp7ImA9WxVVEEk.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-3929490501021532911</id><published>2009-02-27T19:56:00.004-05:00</published><updated>2009-03-02T21:36:54.933-05:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-03-02T21:36:54.933-05:00</app:edited><title>Teaching</title><content type="html">Through an unexpected turn of events, I am teaching &lt;a href="http://inst.eecs.berkeley.edu/%7Ecs172/sp09/"&gt;CS 172&lt;/a&gt; at Berkeley. This is the standard course on Finite Automata, Regular Grammars, Turing Machines, undecidability, NP-completeness, etc. At Berkeley it is a course aimed primarily for seniors (i.e. it comes after Algorithms, Discrete Math, and usually other "advanced" courses).&lt;br /&gt;&lt;br /&gt;&lt;a href="http://www.cs.rutgers.edu/%7Esteiger/"&gt;Bill Steiger&lt;/a&gt; taught the first weeks (finite automata), but unfortunately he has had to return to New Jersey unexpectedly, and I was asked to take over.&lt;br /&gt;&lt;br /&gt;So why did I accept? On the one hand, I can cite &lt;a href="http://en.wikipedia.org/wiki/Richard_Feynman"&gt;Feynman&lt;/a&gt; on why teaching is important: if you research fails for a while, you can at least find comfort in your constant teaching. But since said comfort is so easily found in wine, this does not quite explain it.&lt;br /&gt;&lt;br /&gt;The main reason I accepted was that I remember taking this course with &lt;a href="http://www-math.mit.edu/%7Esipser/book.html"&gt;Mike Sipser&lt;/a&gt; in sophomore year: it was all so much fun. No student needs to go through this! This course should be significantly redesigned, and by teaching it, I can take a stab at the new version.&lt;br /&gt;&lt;br /&gt;The main reasons I dislike the course are: (1) the mental masturbation: teach kids clean unimportant topics (because they're clean and elegant); and (2) the very out-dated perspective, which might have seemed elegant at the time, but with time has proven misleading. Here are some examples:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;the pumping lemma. In the era in which limited state matters (think streaming algorithms), and we have many exciting developments in understanding limited state (by lower bounds), we have students memorize a mechanical way to show that {w w&lt;sup&gt;R&lt;/sup&gt;} is not regular.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;push-down automata. In case you don't remember this: push-down automata are not a nice limited class of machines that can parse grammars --- they are &lt;span style="font-style: italic;"&gt;nondeterministic&lt;/span&gt; !  Grammars that need the whole nondeterministic shebang are parsed via dynamic programs (most famously, the &lt;a href="http://en.wikipedia.org/wiki/Earley_algorithm"&gt;Earley&lt;/a&gt;). More restricted classes are parsed by algorithms with cryptic names, like the LALR parser.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;the lack of exciting stuff in the undecidability section. People in programming languages and databases go on and on about decidable and undecidable logics. Surely there has to be a more exciting example than the &lt;a href="http://en.wikipedia.org/wiki/Post_correspondence_problem"&gt;Post correspondence problem&lt;/a&gt; (and, no, all rights to use "PCP" for this problem have been revoked as of 1990).&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;Turing machines. All computer-looking models of computation are equivalent within logarithmic (often constant) factors. Saying that we cannot fix a model of computation with less than a polynomial imprecision in the running times can only lead to a new generation of seriously misguided theorists.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;the P vs NP fetish. I have too much to say about this, so let's keep it for another post. Suffice it to say that the P vs NP fetish has led to people ignoring major topics like fixed-parameter tractability or SAT sparsification.&lt;br /&gt;&lt;br /&gt;&lt;/li&gt;&lt;li&gt;a dry approach to space complexity. While things like NL= coNL are reasonably interesting, they seem to me far less interesting than space/time trade-offs. The issue of space/time trade-offs (which has some connection to what computation means in the real world) is completely buried by looking only at the space complexity alone, leading to some unexciting language theory.&lt;br /&gt;&lt;/li&gt;&lt;/ul&gt;&lt;br /&gt;My attempts to "fix" the course will be documented on this blog. In the time, please suggest your favorite topic that you think should be covered in introductory complexity courses.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-3929490501021532911?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/3929490501021532911/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=3929490501021532911" title="9 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/3929490501021532911?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/3929490501021532911?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/02/teaching.html" title="Teaching" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">9</thr:total></entry><entry gd:etag="W/&quot;D0YAQn0_eyp7ImA9WxVWEUw.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-2959995874215608532</id><published>2009-02-20T00:29:00.004-05:00</published><updated>2009-02-20T02:32:23.343-05:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-02-20T02:32:23.343-05:00</app:edited><title>FOCS 2009</title><content type="html">Sorry for not blogging. It's not that I've been busy -- it's more like incredibly busy.&lt;br /&gt;&lt;br /&gt;Anyway, the &lt;a href="http://www.cs.yale.edu/focs09/cfp.html"&gt;FOCS 2009 call for papers&lt;/a&gt; seems to be out. Following are the key changes in the call.&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Pre-submission abstracts:&lt;/b&gt; are out. As I said &lt;a href="http://infoweekly.blogspot.com/2009/02/against-pre-submission-abstracts.html"&gt;before&lt;/a&gt;, I am against them.&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Full proofs:&lt;/b&gt; are required for the "central claims in the paper." Essentially, you don't need to prove that 3rd extension of your results that nobody will care about, but you need to write a complete proof of the main result (i.e. the really interesting result for which the paper is being accepted). When SODA'09 introduced this, my gut feeling was slightly against, but with time as a good advisor, I have become a convert. I am glad I managed to push this into the call (it was harder than I had expected...)&lt;br /&gt;&lt;br /&gt;Here are excerpts from mails that I wrote on this topic:&lt;br /&gt;&lt;br /&gt;&lt;tt&gt;[...] It happens too often that people submit a paper vague enough that an interested reviewer cannot even refute (how can you give counter-examples to something that is not fully specified in the paper?). Obviously, the job of conferences is not to check correctness, but if we get lucky with a passionate reviewer, we should allow him to do the job right.&lt;br /&gt;&lt;br /&gt;[...] &lt;i&gt;PCmember&lt;/i&gt; makes a valid point that the committee can (and should) ask for clarifications when a proof is missing or unclear. But this does not rule out the following scenario:&lt;br /&gt;&lt;br /&gt;" Lemmas 13 to 15 don't have proofs in the paper. The reviewers never themselves thought about the problem, and the lemmas appear quite reasonable and straight-forward, so no objection is raised (no need to bother the author for a technicality). After the paper is published, somebody who has thought about the problem reads the proof and has doubts about Lemma 14. What now? "&lt;br /&gt;&lt;br /&gt;The paper should be verifiable not only by the committee (whose emails the author will certainly not ignore!) but also by future readers (imagine the authors' response time if the future reader is a guy with a funny name from China :).&lt;/tt&gt;&lt;br /&gt;&lt;br /&gt;I hope asking for complete proofs becomes standard. As with journals, the main reason to trust the proof is not that somebody else formally checked it, but that the author carefully wrote down a detailed proof. &lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;b&gt;Post-submission description:&lt;/b&gt; This is the biggest innovation in the call. You are supposed to write a 2-page description of your paper one week after the deadline, in which you informally describe the contribution, the main ideas etc.&lt;br /&gt;&lt;br /&gt;I am very sorry that this made it. To be blunt, I think the two main reasons this idea made it were:&lt;br /&gt;&lt;ol&gt;&lt;br /&gt;&lt;li&gt; Some people thought something is "wrong" with current STOC/FOCS and something should be changed. People didn't quite have a consistent story of what was wrong or what should be changed, but the desire of change made the PC agree with the most radical experiment on the table.&lt;br /&gt;&lt;br /&gt;&lt;li&gt; There was no vote (almost nobody responded to a request for a vote). I have no idea whether 75% of the PC supports this, or a vocal 20% of the PC supported it. An unfortunate state of fact.&lt;br /&gt;&lt;/ol&gt;&lt;br /&gt;My formal objection was the following (several people agreed in private emails):&lt;br /&gt;&lt;br /&gt;&lt;tt&gt;Essentially, we can make the conference system as complicated as we want: pre-submission abstracts, double blind, 2-page summary, video at time of submission, rebuttals, a million rules for conflicts of interest etc etc. Some field which obsess about some central conference implement some subset of these ideas (think SIGGRAPH, SIGCOMM etc). Fortunately, in theory we have avoided all this non-sense.&lt;br /&gt;&lt;br /&gt;We are implementing the basic systems principle: keep the interface simple. The process is minimal (submit a paper, get a decision and reviews). Since we have a fast turn-around cycle (with two major conferences a year, plus other reasonable conferences like SODA), there is no need to "bullet-proof" one conference. Any mistake by a PC should be rectified by the next one if the author clears up the misunderstandings in his paper.&lt;br /&gt;&lt;br /&gt;What would the 2-page abstract do? It would force me to cut some arbitrary part of my introduction (I typically have around 4 pages). Why impose this 2 page fixed format for what should be the introduction?&lt;br /&gt;&lt;br /&gt;Also, the 2-page abstracts would sanction the idea that a foggy introduction written at the last minute is ok, since you can rectify it 1 week later. -- Yes, yes, we threated that we may not read the 2-page abstract, but that is also wrong. If we actually don't read it, we seem like the evil PC that just wants to keep authors busy for no good reason. And any argument that "thinking about your contribution 1 week later is good for you" is as annoying as any paternalistic argument.&lt;br /&gt;&lt;br /&gt;Theory has a light-weight process centered on ideas. Anything else should be minimized. Let's keep it simple.&lt;/tt&gt;&lt;br /&gt;&lt;br /&gt;To be clear, everybody seemed to agree that the 2-page description is only an experiment, and future PCs should not borrow it without serious review. I hope it will die after this conference.&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-2959995874215608532?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/2959995874215608532/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=2959995874215608532" title="13 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/2959995874215608532?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/2959995874215608532?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/02/focs-2009.html" title="FOCS 2009" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">13</thr:total></entry><entry gd:etag="W/&quot;CU8HQn4ycSp7ImA9WxVQGEs.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-8929442360377259836</id><published>2009-02-05T14:48:00.004-05:00</published><updated>2009-02-05T14:57:13.099-05:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-02-05T14:57:13.099-05:00</app:edited><title>Against Pre-Submission Abstracts</title><content type="html">&lt;a href="http://www.cs.brown.edu/~claire/"&gt;Claire Mathieu&lt;/a&gt;'s SODA and &lt;a href="http://www.eecs.harvard.edu/~michaelm/"&gt;Michael Mitzenmacher&lt;/a&gt;'s STOC asked for paper abstracts to be submitted one week in advance of the deadline. As the FOCS'09 PC is debating this issue, I wrote the following email expressing my objections. I hope this makes sense to enough people, and we will abandon pre-submission abstracts in theory conferences.&lt;br /&gt;&lt;br /&gt;&lt;tt&gt;I am strongly opposed to the 1-paragraph pre-submission abstracts, so let me try to argue against them.&lt;br /&gt;&lt;br /&gt;Many people, myself included, only write papers in the last week before the deadline. It doesn't matter why this happens, but the PC has to be accommodating. We cannot lecture the community about how they "should" write papers.&lt;br /&gt;&lt;br /&gt;( If the argument about being accommodating is not a strong enough for you, I claim that it is, in fact, the optimal rational decision to only write papers the week before. If you're working on several problems at the same time, you're usually stuck waiting for some brilliant idea to move forward. Such ideas come more frequently when you're relaxed and allow your mind to explore improbable paths --- i.e., such ideas tend not to come in the last week. Writing a formal paper, however, is a much more predictable thing: apply brain power, get the proof. This can be done in the last week, even when sleeping little and working with a time constraint. )&lt;br /&gt;&lt;br /&gt;If we accept the fact that some authors will write papers in the last week, it means that many of the abstracts will not materialize into papers (if a bug is found, or if the writing is not finished in time --- especially likely if complete proofs are required by submission).&lt;br /&gt;&lt;br /&gt;Abstracts that do not materialize into papers are annoying for everybody. For the authors, they are annoying because you have to write an abstract for something that doesn't exist yet, describing some results that might change slightly, and you're not even sure that all proofs will work and you will actually submit!&lt;br /&gt;&lt;br /&gt;For the committee, they're annoying because you are reading and bidding on non-existent papers, generating useless work.&lt;br /&gt;&lt;br /&gt;I don't see why these disadvantages are worth it. After all, we're only saving a few days (eliminating paper proceedings would probably save a month!).&lt;br /&gt;&lt;br /&gt;Cheers,&lt;br /&gt;-mip&lt;/tt&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-8929442360377259836?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/8929442360377259836/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=8929442360377259836" title="20 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/8929442360377259836?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/8929442360377259836?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/02/against-pre-submission-abstracts.html" title="Against Pre-Submission Abstracts" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">20</thr:total></entry><entry gd:etag="W/&quot;CE8HQ3o5eip7ImA9WxVQFE4.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-7241072240485458046</id><published>2009-01-31T13:26:00.004-05:00</published><updated>2009-01-31T15:13:52.422-05:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-01-31T15:13:52.422-05:00</app:edited><title>Morse meets Hamming</title><content type="html">A while ago (2003), I proposed the following problem in the Romanian national olympiad:&lt;br /&gt;&lt;blockquote&gt;You are given an alphabet of &lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt; letters, and the frequency &lt;span class="Apple-style-span" style="font-style: italic;"&gt;p&lt;/span&gt;&lt;sub&gt;1&lt;/sub&gt;, ..., &lt;span class="Apple-style-span" style="font-style: italic;"&gt;p&lt;sub&gt;n&lt;/sub&gt;&lt;/span&gt; with which each letter is transmitted. The goal is to find an optimal &lt;a href="http://en.wikipedia.org/wiki/Prefix_code"&gt;prefix-free&lt;/a&gt; binary encoding for the alphabet (as in &lt;a href="http://en.wikipedia.org/wiki/Huffman_coding"&gt;Huffman coding&lt;/a&gt;). However, the code will be used for transmission over a telegraph, so the cost of a "zero" and "one" are different: a zero (dot) takes 1 second to transmit, and a one (dash) takes 2 seconds. Find an optimal code according to these costs and the given frequencies.&lt;/blockquote&gt;If you are an algorithmist, you will probably have fun thinking about the problem. What is the best running time that you can come up with? (I believe the best known is O(n&lt;sup&gt;2&lt;/sup&gt;); getting any polynomial is already non-trivial.)&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Generalizing this "telegraph problem" to arbitrary letter costs gives an interesting, SODA-esque research question that has been investigated quite a bit, but remains largely open. Say that a "zero" has cost α and a "one" has cost β (say β&gt;α). The &lt;a href="http://www.cse.ust.hk/~golin/pubs/Huffman2.pdf"&gt;best&lt;/a&gt; known running times are n&lt;sup&gt;β+O(1)&lt;/sup&gt;, but the problem is not known to be NP-hard for large β. Can you either show hardness or improve the upper bound?&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;If you are interested in previous work (including approximation algorithms), see &lt;a href="http://www.cse.ust.hk/~golin/PubsBySubject.htm#Prefix Codes:"&gt;Mordecai Golin&lt;/a&gt;'s webpage, and follow references.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-7241072240485458046?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/7241072240485458046/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=7241072240485458046" title="5 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/7241072240485458046?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/7241072240485458046?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/01/morse-meets-hamming.html" title="Morse meets Hamming" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">5</thr:total></entry><entry gd:etag="W/&quot;CEMBSX09fip7ImA9WxVRFUw.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-4880256013416134736</id><published>2009-01-20T23:21:00.002-05:00</published><updated>2009-01-20T23:34:18.366-05:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2009-01-20T23:34:18.366-05:00</app:edited><title>Talk at Berkeley</title><content type="html">A long long time ago, when we took our first computers course, we learned that computers represent things in bits, not in base 10, since bits are easier to store (say, charged vs uncharged capacitor). Well, bits may be easier for computers, but apparently not much easier...&lt;br /&gt;&lt;br /&gt;We can represent an array &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;[1..&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt;&lt;span class="Apple-style-span" style=""&gt;]&lt;/span&gt; of digits using ceiling(&lt;span class="Apple-style-span" style="font-style: italic;"&gt;n&lt;/span&gt; log&lt;sub&gt;2&lt;/sub&gt; 10) bits on a regular computer, such that reading or writing any &lt;span class="Apple-style-span" style="font-style: italic;"&gt;A&lt;/span&gt;[&lt;span class="Apple-style-span" style="font-style: italic;"&gt;i&lt;/span&gt;] value can be done in constant time.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Come hear the details at my talk tommorow (Wednesday, 12pm, Wozniak lounge, Soda Hall, Berkeley). The write-up is forthcoming, and will be posted here.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-4880256013416134736?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/4880256013416134736/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=4880256013416134736" title="5 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/4880256013416134736?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/4880256013416134736?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2009/01/talk-at-berkeley.html" title="Talk at Berkeley" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">5</thr:total></entry><entry gd:etag="W/&quot;Dk4CR3g6eyp7ImA9WxRbGEQ.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-7260282100933162805</id><published>2008-12-10T02:00:00.002-05:00</published><updated>2008-12-10T02:42:46.613-05:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2008-12-10T02:42:46.613-05:00</app:edited><title>Succincter</title><content type="html">'Tis the season to be doing succinct data structures.&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;[P]&lt;/span&gt; My FOCS'08 &lt;a href="http://people.csail.mit.edu/mip/papers/index.html#succinct"&gt;paper&lt;/a&gt; demonstrated how to use recursion to achieve better redundancy. For many fundamental problems, it achieved a redundancy of n / (lg n / t)&lt;sup&gt;t&lt;/sup&gt; bits with query time O(t). The toy problem that people remember from my paper is storing trits: store A[1..n], where A[i] in {1,2,3}, using close to n log&lt;sub&gt;2&lt;/sub&gt;3 bits and fast access to A[i].&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;[Golynski] &lt;/span&gt;In SODA'09, Alexander Golynski (PhD from Waterloo, currently at Google NY) showed a remarkable lower bound for succinct data structures. Suppose you want to represent a permutation π such that you can access π(x) and π&lt;sup&gt;-1&lt;/sup&gt;(x) in time t. Then, your data structure needs redundancy Ω(n lg n / t&lt;sup&gt;2&lt;/sup&gt;) bits. In particular, for constant access time, your data structure needs a constant factor more space than the minimum!&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;This is essentially the first "meaningful" lower bound for succinct data structures. [Gal-Miltersen] did prove a previous lower bound, but for a much harder problem: polynomial evaluation. (For this problem, we believe sublinear query time requires superpolynomial space, so never mind succinct data structures.)&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;Notice that Golynski's lower bound is much higher than my upper bound for storing trits and other problems. His bound is in fact tight for storing a permutation.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;[Viola]&lt;/span&gt; &lt;a href="http://www.ccs.neu.edu/home/viola/"&gt;Emanuele Viola&lt;/a&gt; looks at the trits problem in the bit-probe model and shows that, with bit probe complexity t, the redundancy needs to be at least n / 2&lt;sup&gt;O(t)&lt;/sup&gt;. My result implies a redundancy of n / 2&lt;sup&gt;O(sqrt{t})&lt;/sup&gt; if t is the bit-probe complexity. &lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;As I always want to point out, the true model is the word RAM, but the bit-probe model is sometimes interesting as a mathematical curiosity.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;[Mitzenmacher-Wiener] &lt;/span&gt;Michael has a student working on an implementation of the results in my paper. You could've guessed it &lt;a href="http://mybiasedcoin.blogspot.com/2008/08/on-simulations.html?showComment=1218345900000#c6378973131067956911"&gt;from here&lt;/a&gt;, I suppose.&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;span class="Apple-style-span" style="font-weight: bold;"&gt;[P.-Thorup]&lt;/span&gt; In recent ongoing work, we gave a very strong result for the trits problem: we can achieve a redundancy of exactly 2 bits, with O(1) query time. This completely kills the problem.&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;In the bit-probe model, it immediately implies an upper bound matching [Viola].&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;It is not yet clear whether such strong upper bounds can be extended beyond the trits problem (e.g., for dictionaries and arithmetic coding). But we have some ideas and we are working hard on it (i.e. drinking and hiking).&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div&gt;&lt;br /&gt;&lt;/div&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-7260282100933162805?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/7260282100933162805/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=7260282100933162805" title="4 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/7260282100933162805?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/7260282100933162805?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2008/12/succincter.html" title="Succincter" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">4</thr:total></entry><entry gd:etag="W/&quot;DEEBSXgzeSp7ImA9WxRbEUw.&quot;"><id>tag:blogger.com,1999:blog-786333285568106173.post-99385929544076680</id><published>2008-12-01T02:15:00.002-05:00</published><updated>2008-12-01T02:30:58.681-05:00</updated><app:edited xmlns:app="http://www.w3.org/2007/app">2008-12-01T02:30:58.681-05:00</app:edited><title>B.A.M. 2</title><content type="html">The Berkeley &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_0"&gt;Algorithmists&lt;/span&gt;' Meeting will continue on &lt;span style="font-weight: bold;"&gt;Tuesday&lt;/span&gt; at &lt;span style="font-weight: bold;"&gt;3:30pm&lt;/span&gt;.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Scheduling.&lt;/span&gt; There have been enough calls to change the time that I will do a recount of the votes and probably change it starting next week. If you would like to come and have not sent me your time constraints, please send them ASAP to mip@alum-mit-edu&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;Lecture notes.&lt;/span&gt; There are definite plans to post lecture notes here, though scheduling constraints will delay this for another week or so.&lt;br /&gt;&lt;br /&gt;&lt;span style="font-weight: bold;"&gt;New topic: &lt;/span&gt;Orthogonal&lt;span style="font-weight: bold;"&gt; &lt;/span&gt;Range Queries&lt;br /&gt;&lt;br /&gt;I want to spend a couple of meeting talking about range queries, a hugely important topic (in my opinion) that we don't teach too much of. The theory that has developed around this topic is one of the deepest examples of a coherent theory in &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_1"&gt;TCS&lt;/span&gt; (maybe close to &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_2"&gt;PCPs&lt;/span&gt;, depending on your subjective perception of depth).&lt;br /&gt;&lt;br /&gt;Some ideas we will discuss, in an order &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_3"&gt;TBD&lt;/span&gt;:&lt;br /&gt;&lt;ul&gt;&lt;li&gt;persistence&lt;br /&gt;&lt;/li&gt;&lt;li&gt;predecessor search (especially van &lt;span class="blsp-spelling-error" id="SPELLING_ERROR_4"&gt;Emde&lt;/span&gt; Boas)&lt;/li&gt;&lt;li&gt;buffer trees&lt;/li&gt;&lt;li&gt;&lt;span class="blsp-spelling-error" id="SPELLING_ERROR_5"&gt;RMQ&lt;/span&gt;&lt;/li&gt;&lt;li&gt;the 3D structure of &lt;a href="http://theory.cs.uni-bonn.de/%7Eyasha/"&gt;&lt;span class="blsp-spelling-error" id="SPELLING_ERROR_6"&gt;Nekrich&lt;/span&gt;&lt;/a&gt;&lt;/li&gt;&lt;li&gt;rank/select&lt;/li&gt;&lt;li&gt;lower bounds&lt;/li&gt;&lt;/ul&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/786333285568106173-99385929544076680?l=infoweekly.blogspot.com'/&gt;&lt;/div&gt;</content><link rel="replies" type="application/atom+xml" href="http://infoweekly.blogspot.com/feeds/99385929544076680/comments/default" title="Post Comments" /><link rel="replies" type="text/html" href="https://www.blogger.com/comment.g?blogID=786333285568106173&amp;postID=99385929544076680" title="2 Comments" /><link rel="edit" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/99385929544076680?v=2" /><link rel="self" type="application/atom+xml" href="http://www.blogger.com/feeds/786333285568106173/posts/default/99385929544076680?v=2" /><link rel="alternate" type="text/html" href="http://infoweekly.blogspot.com/2008/12/bam-2.html" title="B.A.M. 2" /><author><name>Mihai</name><uri>http://www.blogger.com/profile/11599372864611039927</uri><email>noreply@blogger.com</email><gd:extendedProperty name="OpenSocialUserId" value="03248219363972237367" /></author><thr:total xmlns:thr="http://purl.org/syndication/thread/1.0">2</thr:total></entry></feed>
