Search This Blog

Solving Boggle with Dart

My friends at work and I have been playing a lot of Scramble with Friends. It's a "tile based word searching game" where you find words on a 4x4 grid of letters. Being a good Dart hacker, I wanted to try writing a small library to find all possible words on the board. Here's how I did it!

Dart, not trad. :)

First off, props to danvk.org and his helpful posts (such as this one) on solving Boggle.

Old 'n busted

My first attend was the naive version. The following code simply tried every possible combination, in a depth-first search. It works, but it's slow. So very slow.

A trie is a tree of strings to values, so I use Dart's generics (aka parameterized types) to clearly annotate that a Trie can hold a specific kind of value T (to be specified by the consumer of this trie).

The real interesting part to me is that the Trie can act as the dictionary as well as the "in progress" tracking. As the solver walks through the tiles on the board, it looks to see if the current node in the tree has a child node for the adjacent tile. If not, the solver simply bails out immediately. No more searching all possible combinations! The new implementation above also does not build the potential word by concatenating strings, character by character. Instead, it just walks the tree until it it finds a word (the word is stored as a value on the left node) or a dead-end.

In action

Here's how I use it in a very simple web app. I was mostly concerned about benchmarks, so there's no UI.

The above Solver and Trie runs in about 1ms on my local machine (finding 33 words in the test board, using my dictionary), which is good enough for me. This is very much a fun weekend project, not meant to be production code. Hopefully it helps you learn a bit of Dart!

Popular posts from this blog

Now, this has to have a built-in somewhere in Scala , because it just seems too common. So, how to convert an Array to a List in Scala? Why do I need this? I needed to drop to Java for some functionality, which in this case returns an Array. I wanted to get that Array into a List to practice my functional programming skillz. **Update**: I figured out how to convert Arrays to Lists the Scala way. Turns out it's a piece of cake. val myList = List.fromArray(Array("one", "two", "three")) or val myList = Array("one","two","three").elements.toList The call to elements returns an Iterator , and from there you can convert to a List via toList . Nice. Because my first version wasn't actually tail recursive, what follows is a true tail recursive solution, if I were to implement this by hand. The above, built in mechanism is much better, though. object ArrayUtil { def toList[a](array: Array[a]): List[a] = { d

In which I port a snazzy little JavaScript audio web app to Dart , discover a bug, and high-five type annotations. Here's what I learned. [As it says in the header of this blog, I'm a seasoned Dart developer. However, I certainly don't write Dart every day (I wish!). Don't interpret this post as "Hi, I'm new to Dart". Instead, interpret this post as "I'm applying what I've been documenting."] This post analyzes two versions of the same app, both the original (JavaScript) version and the Dart version. The original version is a proxy for any small JavaScript app, there's nothing particularly special about the original version, which is why it made for a good example. This post discusses the differences between the two implementations: file organization, dependencies and modules, shims, classes, type annotations, event handling, calling multiple methods, asynchronous programming, animation, and interop with JavaScript libraries. F

In which the virtues of automated mechanical arboreal pruning are extolled over quaint manual labor, as applied to web development build processes. The setup Ever notice how the primary bit of marketing for many traditional web programming libraries is their download size? Why is that? Check this out: Why does size matter so much for these libraries? Your first instinct is probably, "because the more bytes you shuttle across the wire, the slower the app starts up." Yes, this is true. I'd also say you're wrong. The primary reason that size matters for these libraries is because traditional web development has no intelligent or automated way to prune unused code so you can ship only the code that is used over the wire. The web is full of links, yet web dev has no linker The web development workflow is missing a linking step. A linker's job is to combine distinct project files into a single executable. A smart linker will only incl