Version 8 of memoizing

Updated 2004-01-23 15:03:14

I came up with this little proc while lamenting the confusing way that cache functions need to be called in mason [L1 ] - because perl has no way (that I'm aware of) for a subroutine to cause its caller to return, cache functions must be called as

  return if $m->cache_self();

In tcl this can be done much more elegantly. Just call this memoize proc at the beginning of another proc that is expensive to run and it will save the return value so it doesn't need to be recomputed. This makes use of [info level] to examing the stack as well as [return -code] to cause the calling proc to return.

  proc memoize {args} {
          global memo
          set cmd [info level -1]
          set d [info level]
          if {$d > 2} {
            set u2 [info level -2]
            if {[lindex $u2 0] == "memoize"} {
                    return
            }
          }
          if {[info exists memo($cmd)]} {
                  set val $memo($cmd)
          } else {
                  set val [eval $cmd]
                  set memo($cmd) $val
          }
          return -code return $val
  }

A classic use of this is the recursive fibonacci function:

  proc fibonacci {x} {
          if {$x <= 1} {return 1}
          return [expr [fibonacci [expr $x - 1]] + [fibonacci [expr $x - 2]]]
  }

Because this recomputes all lower values for every number, the performance is O(2^n)

  proc fibonacci-memo {x} {
          memoize
          if {$x <= 1} {return 1}
          return [expr [fibonacci-memo [expr $x - 1]] + [fibonacci-memo [expr $x
 - 2]]]
  }

By saving values that have already been computed by simply calling memoize, the performance becomes O(n)


RS: See also Result caching - but this solution here appears more elegant (though a bit brain-twisting) to me. My only proposal to make it more simple is to inline once-used variables, and use eq for string comparison:

          if {[info level] > 2} {
            if {[lindex [info level -2] 0] eq "memoize"} {
                    return
            }

But maybe I'm a bit too much on the FP trip that variables are evil :)


male - 2004/23/01: "FP trip" and evil variables? - RS FP: Functional programming. At least in some FP circles, variables that "can vary", that are reassigned values, are considered as harmful as goto in procedural languages is. Some FPers take great Joy in the like-named Forth-related language where you don't even have (named) arguments to functions - "everything's on a stack".


Category Algorithm | Category Concept