This is great, thanks for the thoughts, gist & links!

On Wed, Apr 24, 2013 at 5:34 AM, Zack Maril <thewitzb...@gmail.com> wrote:

> 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.
>
>
>

-- 
-- 
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.


Reply via email to