Lately, I've been on a bit of a jag into probabilistic programming with Clojure, specifically embedding Church inside of Clojure. The results so far are promising from a syntactic level, but, like David said, getting it to actually work is another matter entirely. I wanted to share what I've been able to get working so far and some of the potential challenges of embedding Church in Clojure.
https://gist.github.com/zmaril/5447488 The above gist is a self contained Clojure program that implements, among other things, `query-by-rejection` and `flip`. With these two functions, we can already do most of what Church seems to do. What's missing from a functionality standpoint is support for various distributions and some useful functions related to tolerance (and, of course, a good MCMC/Gibbs implementation). What's been gained is, via some careful macro writing, the ability to reuse code, specifically to reuse memoized functions. One of the key ideas behind Church is that memoization allows one to express complicated scenarios very concisely. So, to code up a randomized persistent trait (like a person's eye color), you simply define a memoized function that takes in a person and returns their eye color. Every time a new world is generated, the memoized function gets recreated. But within the world (or current experiment), the trait persists and can be referenced again in various places without too much hassle. Note that a new memoized function must be created for each experiment, i.e. you can't just memoize the function outside the query and bring that back in. Within the gist above, binding is used to carefully rebind any function provided in the :memobound clause for each experiment. By declaring a var to be dynamic, we can write queries that are pretty short but all rely on the same logic. >From a syntactic standpoint, it took about one evening of work to cut down the length of most of the Church examples by at least half. >From a speed standpoint, Church is way, way ahead of the above. Sampling via rejection is quite slow compared to modern methods like MCMC or Gibbs. It might not even be possible to do the dynamic rebinding of memoized functions mentioned above and get as fast as Church is. I really don't know. Here's one of the first papers on Church: http://www.stanford.edu/~ngoodman/papers/churchUAI08_rev2.pdf The paper is about five years old now, but section 4.1 goes into how Church was first implemented with a MCMC. The key idea they introduce here is the computation trace. I won't try to summarize it here because I don't fully understand it yet. If it means what I think it means though, then it should be possible to build and keep track of the computation trace thanks to the JVM and Clojure. My intuition says that a very dedicated student could probably produce a Clojure library to catch Church in terms of speed by the end of the summer, simply by emulating what they have done and letting pmap take care of the rest. -Zack On Wednesday, April 24, 2013 12:48:56 AM UTC+4, David Nolen wrote: > > On Tue, Apr 23, 2013 at 2:10 PM, Radosław Piliszek > <radzi...@gmail.com<javascript:> > > wrote: > >> 1) Is this place the best to discuss this? >> > > Yes. > > >> 2) Are there some set goals that CLP(Prob) should achieve? (,,Basic >> support of CLP(Prob).'' does not express it too well! :-P ) >> > > This seems like a pretty challenging one as there are a variety of > possible approaches. Basic support for CLP(Prob) could very well mean > *several* prototypes. That said the probabilistic Prolog variants are > probably worthy of the most study as core.logic is closest to that model. > > >> 3) Is there any API sketch that should be followed? Is it still yet to be >> discussed? And, most importantly, how would you see CLP(Prob) fit in >> core.logic's ecosystem? >> > > There is no API sketch. It's extremely important to survey the links, try > out existing implementations, assess their advantages / disadvantages and > devise a syntax (or several) that works reasonably well with what we've > already established in core.logic. > > Of the projects listed this is probably the most experimental and > research-y. I think if anyone seriously wants to take this on they have to > be extremely focused / self-directed and be willing to put in a > *considerable* amount of time. I'm of course willing to help in whatever > way I can as far as implementation & integration approach - but it will be > a big learning experience for me as well! > > David > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
