memoizing functions the correct, portable way

fare-memoization

FARE-MEMOIZATION

This library builds on an age-old idea: dynamically memoizing Lisp functions.
A memoized function remembers results from previous computations, and
returns cached results when called with the same arguments again,
rather than re-do the computation. This library allows you
to focus on the computation logic and handles the caching part for you.
It also allows you to memoize a function after the fact when you need it.
Obviously, you should only use memoization for functions where it is meaningful:
pure functions that are expensive to compute,
non-deterministic functions for which it matters that choices be consistent,
hash-consing constructors that need return the same result when called with
the same arguments, user-visible constructors for singleton classes, etc.

This file first documents the interface of this library, then
compares fare-memoization to previous memoization libraries,
and finally discusses a false good idea of feature I had.


==== Exported Functionality ====

The fare-memoization library creates a package FARE-MEMOIZATION,
with nickname FMEMO, that exports the following macros and functions:

MEMOIZE SYMBOL &KEY TABLE NORMALIZATION
  This function memoizes the function associated to given SYMBOL.
  If the function was already memoized, it resets
  the associated memoization TABLE and NORMALIZATION function
  to those explicitly specified by this latter call to MEMOIZE, or
  to their implicit defaults (respectively a fresh EQUAL hash-table and NIL).
  Beware that function was declared NOTINLINE, callers are not guaranteed
  to see the memoized function rather than have inlined the original one.
  Moreover, if the function is self-recursive, this
  (declaim (notinline SYMBOL)) must have happened before it was defined.
  Keyword arguments TABLE and NORMALIZATION are as usual (see below).

UNMEMOIZE SYMBOL
  This function undoes what MEMOIZE did to the given SYMBOL.

UNMEMOIZE-1 SYMBOL &REST ARGUMENTS
  This function removes one entry from the memoization cache of SYMBOL.
  It returns T if an entry was found and removed corresponding to ARGUMENTS,
  and NIL if none was found.

DEFINE-MEMO-FUNCTION NAME FORMALS &BODY BODY
  This macro is like DEFUN, but its the defined function will be memoized.
  If NAME is a CONS rather than a symbol,
  the actual name for DEFUN will be its first element, and
  the rest will be a list with keyword arguments TABLE and NORMALIZATION
  as usual (see below).

MEMOIZING FUNCTION &KEY TABLE NORMALIZATION
  This takes a function as argument, and returns a new function that
  calls the given FUNCTION when provided arguments for which
  a result wasn't previously memoized.
  Keyword arguments are as usual (see below).
  Note that if function is self-recursive,
  only the toplevel call will be memoized.

MEMOIZED-FUNCALL FUNCTION &REST ARGUMENTS
  This is a generic way to memoize arbitrary functions on a per-call basis:
  all calls to MEMOIZED-FUNCALL share the same cache, which uses
  the EQUAL hash-table *MEMOIZED* below, and no normalization function.

MEMOIZED-APPLY FUNCTION &REST ARGUMENTS
  This function is to MEMOIZED-FUNCALL as APPLY is to FUNCALL.

*MEMOIZED*
  An EQUAL hash-table, the memoized computation cache for MEMOIZED-FUNCALL.
  You may thus easily (clr-hash *memoized*) to clear the cache of all
  such generic memoized function calls.


The keyword arguments TABLE and NORMALIZATION allow users to customize
the behavior of normalization.

TABLE is the hash-table in which to store the memoized computations.
Its keys will be lists of arguments passed to the function, and
its values will be remembered lists of values returned by the function
when previously called with the respective arguments.
The default value if not specified will be a fresh EQUAL hash-table.
The main uses for explicitly specifying such a table is to be able to
clear the table when the computations are somehow invalidated,
or pre-fill the table with seed values,
so the computations terminate when they reach the edge cases.
You'll usually want any such explicitly given table to be otherwise
reachable, for instance by binding a special variable to it.
The hash-table is an EQUAL hash-table by default, but
you can explicitly pass an EQUALP hash-table if you want.
Since the keys are lists (of arguments),
it is inappropriate to use an EQ or EQL hash-table.
If your implementation allows it and it is meaningful,
you may somehow create a hash-table wherein the keys are weak pointers;
how to achieve such an effect is not portable,
see your implementation's documentation.

NORMALIZATION when non-NIL is a function that normalizes argument lists;
the function is called with a continuation and the function arguments,
e.g. with lambda-list (CONTINUATION &REST ARGUMENTS);
it may transform the argument list before to call the continuation with
a normalized argument list that will be used to query the computation cache
and invoke the actual computation function. NIL means no such transformation,
which has the same effect as specifying #'APPLY as a transformation.
Such a function is notably necessary in cases such as the function
having optional arguments or keyword arguments, wherein you might want
to canonicalize the order in which keyword arguments appear, explicitly
fill in the default values for the various arguments, coerce some arguments
to some appropriate type, possibly upcase or downcase some strings, etc.
This may allow you to reduce the size of the memoization table, but also and
most importantly to make sure two semantically equivalent lists of arguments
(according to the semantics of YOUR application) yield the very same result.


==== Other Common Lisp MEMOIZATION libraries ====

Notable precursors published for Common Lisp include the following.

Marty Hall's 1993 memoization package
	http://www.csee.umbc.edu/courses/pub/Memoization/
as notably published as part of Araneida
	http://www.common-lisp.net/project/araneida/araneida-release/memoization.lisp
It tries to do too much, yet fails in some basic cases:
it treats MEMOIZEing as if it were TRACEing, as something temporary,
done to explore existing program behavior, that can be disabled,
and is not required as part of the permanent semantics of your program
(what with allowing to mass-unmemoize all functions? what if a function's
specified memoization table is essential to its termination?).
The way to customize memoization is not very principled, and its proposed
examples and optional optimizations are invitations to writing bad programs.
At the same time, it won't handle multiple return values, and
it will fail silently in presence of inlining.

The version from Peter Norvig's book
"Principles of Artificial Intelligence Programming"
	http://norvig.com/paip/auxfns.lisp
is a nice quick proof of concept, but
not anything anyone would want to use for real.

Tim Bradshaw's memoize library based on the above,
	http://www.tfeb.org/lisp/hax.html#MEMOIZE
will also fail to handle multiple return values,
dubiously offer to clear all memoized functions,
make it hard to use your implementation's weak hash-table feature.
It has a complex memoized-labels of questionable utility;
with fare-memoization, you can use MEMOIZING or MEMOIZED-FUNCALL
to memoize whichever local function you desire without having
to memoize every function in the same labels,
at a scope you have better control upon.

Finally, there's an earlier version of MEMOIZE that I wrote
as part of my own "Fibonacci" discussion and once made part of FARE-UTILS.
	http://fare.tunes.org/files/fun/fibonacci.lisp
FARE-MEMOIZATION is a more elaborate version of it, with an improved API,
notably regarding the TABLE and NORMALIZATION arguments.


As compared to these precursors, fare-memoization tries to:
* do less, providing only what is strictly needed in real-world uses.
* have well-defined semantics in all cases (modulo documented constraints).
* be portable to all compliant CL implementations without hidden assumptions.
* give maximum control to the user in defining memoization tables.
* have a modern packaging, which these days means ASDF and quicklisp.


==== False good idea not implemented by FARE-MEMOIZATION ====

At some point, I wanted to provide a library function as follows:
(define-memo-function make-the (class &rest keys)
  (apply #'make-instance (find-class class) keys))
But there is no portable way to normalize initialization key list:
not only do you have to sort the keys (which can be done portably as below,
assuming they are all keywords), you first have to merge default initform's
for slots -- and because in practice make-instance and shared-initialize
methods are allowed to do things before, after and around the initform's
depending on provided keys, you cannot do that in a portable way at all.

In conclusion, if programmers want to have classes with objects that are
interned in a table that ensures that two objects are EQ if their keys
verify some equality predicate, they have to develop their own protocol.
Things get even murkier when the creation of some object is requested,
but an object already exists that has a similar keys, yet with other
properties not covered by key equality that differ from the previously
interned object. How are the two objects to be reconciled? This also
requires application-dependent semantics that the protocol must allow
the programmer to specify.


define memoized functions and memoize previously defined functions

fare-memoization

Upstream URL

Author

License

fare-memoization

Version:

License:

Authors:

Dependencies:

fare-memoization/test

Version:

License:

Authors:

Dependencies:

Dependencies (1)

Dependents (4)