Introduction to Tries
drmcawesome.com
drmcawesome.com
edit: note that its not strictly a trie, but can be used as one, in general its more like it does a trie-like key value lookup.
edit: it is also worth noting that its pretty fast, counting reading data in from the file system and other overhead, loading 1.5 million key - value pairs of realworld production data into the trie, and then making my first query, in under 30 seconds. And thats without even doing the sort of preprocessing that can make it much much faster! (namely, lexigraphically sorting the strings I'm using as keys before doing the k-v insertions)
or this one which is slightly harder: http://linux.thai.net/~thep/datrie/datrie.html
The article skims over the tricky part - the dependency on the size of the alphabet. Which you can no longer treat as insignificant in the days of unicode.
Does anyone know, is there a Unicode encoding that enables you to map arbitrary ranges (so I can, for example, use the greek alphabet only at 1 byte per character or less)? I suppose UTF-8 is already hard enough to decode.
There are some new implications you need to account for if you do this, as you no longer have one node per letter, but a path per letter. E.g. subtrees will no longer correctly represent substrings, making autocompletion slightly trickier.
I also dynamically allocated the key/pointer arrays within each node so that while it was sparsely populated, it was only big enough to hold the largest byte defined in that node (e.g. - 'A' = (char) 65, so byte positions 0 to 65 would be present, but not 66 to 255 until needed.
I was nice to see the impression of my coworkers when a bunch of qsort() / bsearch() code was replaced with this. We could afford the memory, and the speedup was fairly impressive.
Following the etymology, the inventor, Edward Fredkin, pronounces it /ˈtriː/ "tree".However, it is pronounced /ˈtraɪ/ "try" by other authors.