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.
