Fantastic - thanks for pointing these out. On Friday, 26 April 2013 08:43:07 UTC+1, Zack Maril wrote: > > 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.
