Nils also wrote his work up: http://ozk.unizd.hr/proceedings/index.php/els/article/view/102/106 -Zack
On Friday, April 26, 2013 6:33:55 AM UTC+4, Maximilien Rzepka wrote: > > For the sake of completion ;) > > Nils Bertschinger's work > https://github.com/bertschi/ProbClojureNice > https://groups.google.com/forum/?fromgroups=#!topic/clojure/9NhsFga4D9s > > Le mercredi 24 avril 2013 11:34:14 UTC+2, Zack Maril a écrit : >> >> 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>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.
