Moving to jeremy-chen.org

I'm moving to http://jeremy-chen.org/. Mostly.

I plan to use that site as a "self-marketing website" of sorts and to manage content in a way that I would otherwise not be able to do on blogger alone.

This blog will stay, ostensibly for more provisional ideas prior to refinement. I'll be gradually moving content (I still like) over to the other website. =)

Thursday, June 28, 2012

Operationalizing HDB Balloting with Multiple Selections

Some thoughts:
    What kind of housing comfortably houses 1 person? What kind of housing comfortably houses 2 people? What kind of housing comfortably houses 2+1? And 2+2? How about 2+3? Is 2+4 even advisable given it is public housing?
These correspond, perhaps, to five flat types: shoebox, 2 room, 3 room, 4 room, and "actual" 5 room flats. (Where number of "bedrooms" = number of "rooms" - 1.) But what about those that need a little more space but not that much more and cannot afford to pay for that little bit of extra space? What if low income households whose affordability range is at about a house for 2 want to have 1 kid but can't afford going all the way to a 3rm flat. A 2rm with a larger living room perhaps.

Suppose we add 2 shoebox variants, 2rm+, 3rm+, 4rm+, actual 5rm+ for a new total of 11 flat types. Taking the shoeboxes out (shoeboxes relate more to "lifestyle choice" than "income"), we have 8 flat types that allows for better pegging to income level due to less "sandwiching".

Now there is a new problem of how to handle balloting since the number of flats per type becomes much smaller. It is no longer practical to ask for applicants to indicate only a single flat type. The reality is, it probably is more sensible to ask applicants to indicate 2 to 4 choices (in the same development) in order of preference. How to implement the balloting process now becomes the problem.

Given a few ballot orders and the preferences of balloters, how do we allocate flats well. Can we obtain an allocation where no two balloters would be willing to perform mutual swaps of numbers for one or more of their choices? (The "no-envy" condition.)

Let me describe a simple process that provides a result that satisfies that "no-envy" condition.
  1. Balloters get numbers for all the flats types that they have indicated a preference for. (Recall these are in the same development.)
  2. Pairs of balloters are compared in a random order to make them happier by mutual swaps of their ballot numbers. At the end of this process, the "no envy" condition will be satisfied.
At this point, we can stop and have people make appointments to select flats in order of ballot number. (These appointments for the same development should be approximately concurrent.) Balloters should be instructed that missing or cancelling an appointment is equivalent to giving up a number, so they may gamble on others not selecting flats at their own risk. (The selection of a flat cancels all other appointments.) If this option is selected, we are done.

(If there are theoretical questions on the resulting ballot numbers I think I can answer them. Like given a set of ballot orders and preferences, is the "no envy" allocation generated from this random process unique? The answer to that one is no due to the random comparison order. So it is not "optimal" in a sense, though "optimal" is hard to quantify rigorously due to the number of conflicting interests. We'll leave theory to another day, if there is interest.)

On the other hand, if it is desirable to pare down the number of appointments on paper, it can be done, but the algorithm I can think of is not so rigorous. (A better way is to incentivize people to give up the appointments they do not really need through a small price discount, say $500 per appointment dropped.)

In any event, it is not hard to give those balloting for flats more choices. Why can't someone's application read:
  1. Geylang (4 rm)
  2. Kallang (4 rm)
  3. Hougang (4 rm)
It is just a matter of getting the math sort of right. Which means incentive compatibility, which I haven't explored.

No comments: