Will's blog

purpose: Will Kahn-Greene's blog of Python, Linux, random content, PyBlosxom, Miro, and other projects mixed in there ad hoc, half-baked, and with a twist of lemon

Tue, 12 Jun 2007

Using register allocation algorithms for determining table layout

S and I decided to assign tables for our guests during the wedding reception. There were a bunch of good reasons for doing this which I'm not going to go into here. However, assigning 100 or so guests to 10 or so tables while maximizing "goodness" and minimizing "badness" isn't trivial to do on paper by hand. At some point during wedding planning, I decided we could do table layout with a modified register allocation algorithm. This is a quick summary of translating register allocation into table layout along with some commentary on how this works nicely and also where it doesn't quite work.

More after the jump....

----

Register allocation is typically done using graph-coloring with some additional bits that turn the NP-complete graph-coloring algorithm into a linear-time one that results in a good approximation. Andrew Appel talks about register allocation in his book on compilers entitled Modern Compiler Implementation in ML in chapter 11. It involves a graph of nodes representing temps connected by edges that represent interference between the temps. There's also a list of move-related nodes and nodes related by move-edges are coalesced if possible leading the connected temps to be colored with the same register.

In table layout, there are groups of people who can't sit at the same table with other groups of people. This could be due to family issues, differences in politics, past history, ... Additionally, there are groups of people you want to sit at the same table with other groups if possible.

Let's do some substitution. We'll substitute registers for tables, edges representing people who can't sit at the same table as interference, edges representing people who would be good sitting together as move-related, and temps as people and we have mapped the register allocation problem into a table layout problem.

I'm not going to go into the details of register allocation--Appel talks about the George and Appel algorithm from "Iterated register coalescing" (1996) for 25 pages and it'd be hard to summarize that into a blog entry.

There are a few things that don't translate well from register allocation to table layout like spilling. In register allocation if you can't get it to work you spill a temp into memory and then start over. I suppose you could uninvite particularly ornery people, that's one possible mapping for spilled temps. Another possibility is that you look for the least-worst pairing and remove that edge from the graph. A third possibility is to break up a larger table into two smaller tables giving you an extra color to work with.

Speaking of tables, there's one big difference between tables and registers: a register can be assigned to an unlimited number of temps so long as they don't interfere with one another. A table has a limited number of seats. So if you were to use a register allocation algorithm, you have the additional constraint that a limited number of people can be assigned to each table. If the register allocation implementation that you use is deterministic, this constraint could cause your situation to be unsolvable without backtracking. It would be a good idea to introduce a random element that causes assignments to occur in different orders between iterations.

The move-related edges (which represent people who should be sitting together) could be prioritized and that priority could be used for selecting moves to coalesce. For example, you might want to keep couples together and perhaps families, too. Perhaps you want to put all the children at a single table that you can put close to the bathroom.

Theoretically, this sounds like it would work pretty well for many cases, at a minimum returning a layout that can be tinkered with. We never used this method--by the time I had finished grad school, S was already past most of the table layout issues.

It's possible the constraint on people per table handicaps the register allocation algorithm to such a degree that it would be better to use a more general purpose constraint satisfaction problem solver instead. This requires further study.

Posted by Doug Napoleone on Tue Jun 12 16:00:12 2007
Why didn't I think of that?

P.S.: send me your resume assuming you don't mind a commute to Burlington MA.


Posted by Grok2 on Tue Jun 12 19:41:58 2007
Or you could just use http://www.perfecttableplan.com/...


Posted by BioGeek on Wed Jun 13 06:53:38 2007
Reminds me of how Mark Jason Dominus wrote a Makefile to read a raw data file with Perl and generate the seating chart for his wedding in LaTex.


There's a line in one of William Gibson's short stories about how some situations call for a subtle and high-tech approach, and others call for a sawed-off shotgun. I think my success as a programmer, insofar as I have any, comes from knowing when to deploy each kind of approach.

In a recent article I needed to produce the table that appears at left. This was generated by a small computer program. I learned a long time ago that although it it tempting to hack up something like this by hand, you should usually write a computer program to do it instead. It takes a little extra time up front, and that time is almost always amply paid back when you inevitably decide that that table should have three columns instead of two, or the lines should alternate light and dark gray, or that you forgot to align the right-hand column on the decimal points, or whatever, and then all you have to do is change two lines of code and rerun the program, instead of hand-editing all 34 lines of the output and screwing up two of them and hand-editing them again. And again. And again.

When I was making up the seating chart for my wedding, I used this approach. I wrote a raw data file, and then a Perl program to read the data file and generate LaTeX output. The whole thing was driven by make. I felt like a bit of an ass as I wrote the program, wondering if I wasn't indulging in an excessive use of technology, and whether I was really going to run the program more than once or twice. How often does the seating chart need to change, anyway?

Gentle readers, that seating chart changed approximately one million and six times.



Posted by will on Wed Jun 13 11:30:52 2007
re: Grok2

That's an interesting looking program.  I'd love to know what algorithm they use for doing automatic seat assignment.


re: BioGeek

That's awesome!

We also went through many iterations of the table layout--half of them triggered anytime we discovered a new guest was coming or an existing guest had other plans.  So I can relate to Mark's plight.  S did most of the work in Excel I think.  If I had been more involved, I would have written a program to do the brunt of the work for us.


Posted by Andy Brice on Wed Jun 13 12:17:29 2007
Will,

PerfectTablePlan uses a genetic algorithm.


Please keep comments appropriate. I reserve the right to remove anonymous comments, flames, spammy, inappropriate, and other comments that I deem to be worth removing.

Note: New comments get placed in a "draft" status and will NOT show up on the site until I explicitly approve it. Usually that happens within 24 hours, but sometimes I go away and it takes a day or two.

Note 2: There is now a preview button for those of you who want to see a preview! However, it doesn't quite work the way you'd think it should work. I'll look into adjusting it some day.

Note 3: If you can't for some reason post a comment, send me an email: willg at bluesock dot org.

Your name:


Your e-mail address (this doesn't get displayed to anyone--I use it to contact you if there are issues):


URL of your website (optional):


Comment:


Yes, I am a human!

pyblosxom::2.0 dev

All contents Copyright 1996 to 2008 Will Guaraldi.
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.