probcomp / Venturecxx

Primary implementation of the Venture probabilistic programming system
http://probcomp.csail.mit.edu/venture/
GNU General Public License v3.0
28 stars 6 forks source link

Can we view a trace as an "active memory" rather than an "execution history"? #655

Open axch opened 7 years ago

axch commented 7 years ago

What if we think of the traces as primary, and the "model program" as just adding color? [This is motivated by thinking about trace literals and the consequences of that view.] That seems like it would look something like this:

  1. There is a type of data store called an "active memory", for lack of a better term (formerly called a "trace").

  2. An active memory is first of all a memory, that is, a way to store a bunch of values at a bunch of locations.

  3. The thing that makes it active is the option to specify (probabilistically incomplete) intended relationships between the values at various locations, as well as between values in some locations and the presence of, absence of, and relationships among other locations; and then to look for incarnations of the memory that satisfy those relationships more rather than less.

  4. Those relationships are specified by terms of a programming language, Lispily the same one as the "host" in which these "active memory" structures are available as data.

4a. Consequently, the memory needs to be able to store things like primitive procedures, compound procedures, and lexical environments.

  1. There needs to be some mapping between the progress of evaluation of terms and the keys in the store. In Mite that mapping is obtained by requiring the keys to be addresses, and understanding how the interpreter of terms assigns addresses to evaluated subterms.

What are the consequences of this view?

  1. "traced evaluation" is elaboration of an empty region of an active memory with values sampled from the relationship of that region on nearby, "previous", non-empty regions.

  2. "regeneration" is completion of a partially empty region of an active memory in light of relationships with surrounding regions. There are many different ways to regenerate, which are different proposal distributions for the fill-in.

7a. "traced evaluation" is in one sense a special case of "regeneration", in that it is regeneration from the prior. However, it can also reasonably be viewed as a distinguished special case, in the sense that it's the only reasonable thing to do if you know you will not second-guess (i.e., do inference on) the results.

7b. The infinite upward regress stops at "evaluation" or "forward sampling". The infinite downward regress stops at computations that are known to be deterministic.

  1. A clean implementation of this view would need to rewrite the "interpreter" to assume that traces may have all sorts of junk inhabiting them already, and have very clear behavior around finding stuff already present. In that sense, this view is a philosophical resolution to the multiple request registration problem https://github.com/probcomp/Venturecxx/issues/650, which is really a trace-evaluation invariant specification problem.

  2. Whether something is an "observation" or not is now a tag to generic inference programs not to tweak it. This information doesn't need to be part of the active memory as such.