Lambda Lifter

1. Lambda Lifter ICFP Programming Contest 2012 as seen by Alex Popiel a.k.a. Invisible Imp

2. Outline • Description of problem • Basic solution approach • Standard Scaladatastructures that make it easier (if you remember to use them) • ListMap with default to Array • PriorityQueue

3. What is it? • http://www.icfpcontest.org • 72 hour contest from 7/13 to 7/16 • Teams of arbitrary size, from anywhere in the world • Run this year by a group from St. Andrews University in Scotland • Specification given at beginning of contest, no prior knowledge

4. No, really, what is it? • Playing a modified version of Boulder Dash • Have a 2D grid of squares which may contain walls, soft earth, open space, rocks, lambdas, the exit, or you (as a robot) • Your task: dig through the open space and earth to collect all the lambdas, then go to the exit • Rocks can be pushed into empty space; unsupported rocks fall in deterministic ways, can block the way out or kill you

5. But wait, there's more! • 4 separate specification updates (with major game features) released over the course of the contest, the last just over 24 hours before the end of the contest. • rising water (will kill you after x turns submerged), • trampolines (single-use non-local transport), • beard moss & razors (obstacles that grow), • higher-order rocks (must make rock fall to expose embedded lambdas)

6. And now, in CS terms • Traveling salesman over a mutable field of arbitrary size • Traveling salesman by itself is NP-hard, but good heuristics are known • Mutable field due to falling rocks throws much of that out the window • Easy to solve for small grids, but input size limited only by judge's whim (up to 4 gigabytes)

7. How to solve it? • Each game move represented as a state transition • State-space search using modified A* • Use gradient floodfills ignoring rocks and beards for the future cost underestimate • Many states held concurrently in a priority queue – state representation must be small

8. State Representation • Store initial state as large array of characters for reasonably compact handling of large maps • Single dimensional array with different directions just being different offsets from current location – reveal symmetries between directions • Store modified maps as scala.collection.immutable.ListMap with default to the initial map

9. Fast State Updates • The rules specify state updates as a scan of the entire map, but that's too slow for large maps • Maintain lists of locations that might change, and only process those (empty space below rocks, beards with empty space around them) • Speedup proportional to fraction of map filled with changing space, at least 0.5 reduction.

10. State expansion queue • A* optimal path search uses a sorted list of pending states to explore • scala.collection.mutable.PriorityQueue is a reasonably efficient implementation using a heap • Just need to declare your Ordering, e.g. implicit val order = new Ordering[State] { def compare(x: State, y: State): Int = x.priority - y.priority } valqueue = new scala.collection.mutable.PriorityQueue[State]

11. Summary • Scala standard collection library already contains many data structures perfect for game state searches • I don't know the library well enough, ended up not taking advantage of it until too late • I still don't know the library well enough… while writing this I made more unit tests around the details of Map.WithDefault, and discovered it behaved differently than I thought • My code is available at https://github.com/popiel/icfp-2012