blockquote {
margin: 2em;
padding: .1em 1.5em;
position: relative;
background: #2F2F2F;
}
">

[...] Initial tests of Tries: Follow Up [...]

There has been work on doing just that, its the ‘conditional rotation’ heuristic and it works really well… imperatively.

http://www.bcs.org/upload/pdf/oommen.pdf

Unfortunately, there is a cost intrinsic in a functional implementation that isn’t experienced by an imperative implementation of the same idea:

It involves mutation to update the count functionally, which means you spew out garbage, which has to be collected, and worse, this happens on reads, not writes.

Consequently, reads which previously didn’t tax the GC at all, now generate garbage. This same problem tends to affect functional splay trees. And to a lesser degree, explains why even rebalancing (which only occurs during writes!) in a mutation-free setting is more expensive than elsewhere, because imperatively you are free to relink the existing tree rather than allocate and relink all the way to the root.

Thanks a lot for the feedback. I’m realizing how tricky it is to create a good data structure like this.

I’ve been a little busy, but want to re-write MagnusTree using some balancing schemes that occurred to me and that I was curious about:

I realized that when searching for a branch to continue down the Trie, we want to keep the most common branches closer to the root (of this particular node of the Trie). It would be pretty easy to come up with a Trie of weight-balanced tries:

we could either store an integer at each node and increment it each time we “enter” back into the Trie at that branch, then do one rotation upwards if we see that the weight of our branch is greater than the parent branch.

an alternative involving more rotations, but which doesn’t need to store weights might be to simply rotate a branch upward every time we match its element and enter it, keeping the common nodes hopefully close to the top.

For the ternary trie, all I was using we a left/right split based comparison with the key element or a center leg for when the partial key matches, which when made out of simpler parts rather than flattened and specialized would look like:

data Tern k a = Tern !Int !k !(Maybe a) !(Tern k a) !(Tern k a) !(Tern k a) | Tip
data Trie k a = !(Maybe a) :> !(Tern k a)

that can then be optimized by flattening, specializing, including runs ala PATRICIA using UArr’s, unpacking, even hash consing leaves to obtain a DAWG, etc.

You’ll note that looks a lot like Data.Map, but you can balance it using either the entire mass of nodes underneath or the number of leaves in the trie, rather than purely using the local weight of the single level of the Data.Map, so it gets a better weighting system. You probably want to set the delta higher than in Data.Map though to do less rebalancing work, especially if you use mass.

@jberryman

You can get a 30% speedup on Magnus’ tries by specializing them ala the work we’ve been doing on adaptive-containers:

data CharIntTrie
= NothingNothingNode
| JustNothingNode !Int
| NothingJustNode !Char !CharIntTrie !CharIntTrie !CharIntTrie
| JustJustNode !Int !Char !CharIntTrie !CharIntTrie !CharIntTrie
| NothingSimpleNode !Char !CharIntTrie
| JustSimpleNode !Int !Char !CharIntTrie
deriving (Show)

and a much smaller win can be obtained by doing a worker/wrapper transform on insertWith

insertWith :: (Int → Int → Int) → String → Int → CharIntTrie → CharIntTrie
insertWith f s v t = go t s where

go (NothingJustNode head lesser tail greater) [] = JustJustNode v head lesser tail greater
go (NothingJustNode head lesser tail greater) aas@(a:as) =
case compare a head of
LT → NothingJustNode head (go lesser aas) tail greater
EQ → NothingJustNode head lesser (go tail as) greater
GT → NothingJustNode head lesser tail (go greater aas)
…

but thats all you’ll get without using some array (UArr/Bytestring) style packing for compaction.