5

I find this answer and this wiki page to be excellent introductions to memoization in Haskell. They do, however, still leave me with a question that I hope to get answered:

It seems to me that the technique used requires you to "open up" (as in "access the internals of") the data structure you use to store your memoization. For example, 1 implements a table structure and 2 implements a tree in section 3. Is it possible to do something similar with a pre-made data structure? Suppose, for example, that you think that Data.Map is really awesome, and would like to store your memoized values in such a Map. Can one approach memoization with a pre-made data structure such as this, where one does not implement the structure itself, but rather use a pre-made one?

Hopefully someone will give me a hint on how to think, or, perhaps more likely, correct my misunderstanding of functional memoization in general.

Edit: I can think of one way to do it, but it's not at all elegant: If f :: a -> b, then one can probably easily make a memoized version f' :: Map a b -> a -> (Map a b, b), where the first argument is the memoization storage, and the output pair contains a potentially updated storage and the computed value. This state-passing is certainly not what I want (although I guess it could be wrapped in a monad, but it's several orders of magnitudes uglier than the approach in 1 and 2).

Edit 2: Maybe it helps to try and express my current way of (incorrect) thought. Currently, I seem to repeatedly pull myself, against my will, into the non-solution

import qualified Data.Map as Map
memo :: (Ord a) => [a] -> (a -> b) -> (a -> b)
memo domain f = (Map.!) storage
    where
      storage = Map.fromList (zip domain (map f domain))

The more I stare at this, the more I realize I've misunderstood something basic. You see, it feels to me that my memo [True, False] is equivalent to the bool memoizer of 1.

Community
  • 1
  • 1
gspr
  • 11,144
  • 3
  • 41
  • 74
  • Ugh. Reading Dan's answer, I became convinced that there's actually nothing wrong with the code in "Edit 2". It turns out I was just profiling wrongly. It's working fine :-) – gspr Apr 01 '11 at 15:04

1 Answers1

3

If you notice, Data.Memocombinators actually relies on the "pre-made" Data.IntTrie. I'm sure you could take the same code and replace uses of the IntTrie with another data structure, though it may not be as efficient.

The general idea of memoization is to save computed results. In Haskell, the easiest way to do this is to map your function onto a table where the table has one dimension per parameter. Since Haskell is lazy (well, most data structures in Haskell are), it will only evaluate the value of a given cell when you specifically ask for it. "table" basically means "map" since it takes you from key(s) to value.

[edit] Additional thoughts regarding Example 2

If I'm not mistaken, then the first time (Map.!) storage is forced to evaluate for a given key, the storage structure will be entirely wrung out (though the computation f won't happen for anything but the given key). So the first lookup will cause an additional O(n) operation, n being length domain. Subsequent lookups would not, afaik, incur this cost.

Lazier structures like typical int-indexed lists or the IntTrie similarly need to manifest their structure when a lookup is invoked, but unlike a Map, they need not do so all at once. Lists are wrung out until the indexed key is accessed. IntTries wring out only the integer keys that are "prefixes" (or suffixes? not sure. could be implemented either way) of the desired key. Index 11, (1011) would wring out 1 (1), 2 (10), 5 (101), and 11 (1011). Data.Memocombinators simply transforms all keys into Ints (or "bits") so that an IntTrie can be used.

p.s. is there a better phrase than "wring out" for this? The words "force", "spine", and "manifest" come to mind, but I can't quite think of the right word/phrase for this.

Dan Burton
  • 53,238
  • 27
  • 117
  • 198
  • 3
    It's important to recognize that the feature that distinguishes `IntTrie` from `Map` is its laziness -- its ability to store values for infinitely many keys. You have to add mappings "one at a time" to `Map`, so it can only ever have finitely many mappings, and thus you couldn't use it to store values for an infinite parameter space (which most interesting parameter spaces are). – luqui Apr 01 '11 at 15:19
  • 1
    (re: laziness in storing values for infinite keys) An `IntTrie` is comparable to a simple `List` in this regard. But to get to entry 1000, you have to traverse through (though not necessarily compute the result of) the 999 entries preceding it in a List. With an IntTrie, you traverse only through log(1000) = ~10 entries. – Dan Burton Apr 01 '11 at 16:09
  • 1
    "In Haskell, the easiest way to do this is to..." use the monad-memo package, which I just discovered is cooler/easier than I expected. – Thomas M. DuBuisson Apr 01 '11 at 16:15