Re: [ANN] Fluokitten - Category theory concepts in Clojure - Functors, Applicatives, Monads, Monoids and more
Hi, Am Mittwoch, 3. Juli 2013 16:49:43 UTC+2 schrieb Dragan Djuric: Monads as a Haskell construct is what the previously mentioned laws describe. Monads in category theory are defined in a category X as a triple (T, n, m) where T is a functor and m and n certan natural transformations such that certan diagrams commute. In that sense, I am not sure that even Haskell's implementation is perfectly clean. in category theory, monads are functors with additional constraints. Haskell's implementation is clean to the extend that Hask, i.e Haskell types and morphisms between them, form a category (there are some issues with laziness). The connection to the categorical definition is most easily seen if you define monads using join instead of = (bind). You basically need a functor, i.e. a type constructor with a proper fmap (check the laws here as well), and two natural transformations mu, eta. As it turns out, polymorphic functions are natural transformations in Haskell's category, i.e. they always obey the required laws, no need to check them. Let's call your functor type t, then mu and eta have the following types: mu :: a - t a -- Haskell's return eta :: t (t a) - t a -- Haskell's join The required laws now state that: eta (eta mm) = eta (fmap eta mm) eta (mu m) = eta (fmap mu m)= identity which just says that if you have something of type t (t (t a)) it does not matter whether you flatten it from the inside or outside first and if you have something of type t a, you can put it into another t from the outside or inside and flatten it to get back the identity. Now, conceptually changing the monad does not make much sense. Remember that a monad is a functor with additional structure, so we are always working in the same functor! The laws just express that we have a special functor which obeys additional properties, besides the functorial ones. Also generalizing the types of (=) to support different monads is forbidden by the laws. Try to define myBind :: (Monad m, Monad n) = m a - (a - n b) - n b-- like (=), but changes the monad and now look at the second law: x = return = x or written with explicit types: ((x :: m a) = (return :: a - m a)) :: m a = x :: m a ((x :: m a) `myBind` (return :: a - n a)) :: n a but this cannot equal (x :: m a), since it does not even have the same type! Best, Nils -- -- 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.
Slime hack for REPL testing
Hi everyone, I just did a small hack for swank-clojure which has the repl thread hold the last three input forms in variables **1, **2 and **3 respectively. Based on this, I added a slime function slime-extract-test which does the following: user (range 7) (0 1 2 3 4 5 6) user (range 3) (0 1 2) user (concat *1 *2) (0 1 2 0 1 2 3 4 5 6) -- 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
Slime hack for REPL testing
Hi everyone, just finished a small hack for swank-clojure (see my fork on github: github.com/bertschi/swank-clojure) The repl thread now has access to the last three input forms that were typed into the repl. These forms are accessible as **1, **2 and **3 respectively. The Common Lisp names +, ++ and +++ would not work in Clojure and the output forms are numbered *1, *2 and *3, so this is what I came up with. Based on this functionality, I added the Emacs function slime-extract- test. To explain what it does, here is an example. Imagine the following repl interaction: user (range 7) (0 1 2 3 4 5 6) user (range 3) (0 1 2) user (concat *1 *2) (0 1 2 0 1 2 3 4 5 6) Now, hit M-x slime-extract-test and this gets transformed into an expression suitable for clojure.test (is (= (concat (range 3) (range 7)) '(0 1 2 0 1 2 3 4 5 6))) which is written into a Testing buffer. What do you think? Any use for that? Nils -- 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
Re: Slime hack for REPL testing
Hi Stefan, On Feb 27, 3:23 pm, Stefan Kamphausen ska2...@googlemail.com wrote: Hi, extracting forms from the REPL session into some test-magic definitely is useful. However, my sessions seem to be structured in a different way and only having access to the previous three inputs doesn't seem viable to me. I think, I'd prefer a REPL where I would tell swank to start recording my stuff and later extract all the interactions which didn't yield an exception. Mind, that this is just guessing what would feel right, though. thanks for your thoughts. It is really the simplest solution that I could think of and does not necessarily fit everyones workflow. I tend to use very short snippets at the repl which are usually self contained, i.e. do not depend on defined variables, but rely heavily on *1, *2 as shortcuts to save typing. Up to now, I did not bother much to make unit tests out of my repl experiments. This mode hopefully improves on that ;-) Best, Nils Kind regards, Stefan -- 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
Re: letrec
Hi, to implement letrec in a language with eager evaluation strategy some kind of mutability is probably needed. Consider for example a self- referential definition such as (let [fibo (lazy-cat [1 1] (map + fibo (rest fibo)))] (take 10 fibo)) This will not work since fibo is not in scope when the binding is established. The standard solution would probably be something like this (let [fibo (promise)] (deliver fibo (lazy-cat [1 1] (map + @fibo (rest @fibo (take 10 @fibo)) Not as nice as the original version due to explicit dereferencing, but workable. As an alternative one could use a macro to expand to this and use a code walker (or symbol-macros) to automatically include the @ calls. The following is untested, but should be close: (defmacro letrec [binding body] (let [[var expr] binding g-var (gensym)] `(let [~g-var (promise)] (symbol-macrolet [~var @~g-var] (deliver ~g-var ~expr) ~@body and voila (letrec [fibo (lazy-cat [1 1] (map + fibo (rest fibo)))] (take 10 fibo)) produces (1 1 2 3 5 8 13 21 34 55). Best, Nils -- 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
Re: Agents vs. Actors
Hi Benny, On Dec 3, 9:21 pm, Benny Tsai benny.t...@gmail.com wrote: Hi Nils, A while back, I also took a stab* at implementing Erlang-style actors in Clojure, along with solutions for a few classic concurrency problems (Dining Philosophers, Sleeping Barber). I was blown away by how easy it was to implement actor semantics on top of agents. looks good. Somewhat different approach where the state of the agent is handled more explicitly. I tried to stay close to Erlang, so the state is wrapped in a closire which acts as my matching function. It might also be interesting to solve some of those classic concurrency problems the Clojure way and compare to the actor solutions. Comparing our respective efforts, I see a lot of room for improvement in mine :) I like how your actors send messages containing the address of the recipient, which seems truer to the actor model. Also, you raise a great Actually, I do not include the address of the recipient into the message. The message is simply a symbol and then dispatched in a case statement. The example might be slightly confusing since the actors are named :ping and :pong and send messages ping and pong to each other. It's really a very simple sketch ... no pattern matching on messages and no mailboxes. point regarding pattern matching; I think that can greatly simplify the message handlers in my code. Looks like it's time for me to get acquainted with core.match :) This seems to be the right approach to fake Erlang-style message handlers. Thanks for the food for thought! *https://github.com/bitsai/clojure-actors -- 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
Re: delayed recursive macro expansion?
Hi Andrew, the approach suggested by Tassilo looks correct. Macros are evaluated at compile-time, so you need a termination condition that can be decided without actually running your form. In you're case you want run-time delayed evaluation, which is easily achieved by wrapping the expression into a closure. On Dec 3, 6:45 pm, Andrew ache...@gmail.com wrote: Aren't the calls to itry-the-fn different from the calls to itry-the-macro? For example, let's say my expr is (/ a b) where b is currently zero and maybe the user decides to set a new value for b when prompted. itry-the-macro can be called this way: (itry (/ a b)) and is able to print out the source code (/ a b) for the user as a string if it needs to. itry-the-fn has to be called this way, right? (itry (fn [] (/ a b)) and is unable to print out the source code of the expression. Let me know if I'm mistaken. You are right about the calling interface. itry-the-fn needs to have its argument delayed explicitly, i.e. (itry (fn [] (/ a b))), and cannot look into the form. A standard way to solve this problem is to define both, a function and a macro which provides a more convenient interface to the function. (defmacro itry-the-macro [expr] `(itry-the-fn (fn [] ~expr))) or in case you want to preserve access to the source code of the expression: (defmacro itry-the-macro [expr] `(itry-the-fn (fn [] ~expr) '~expr))) and itry-the-fn takes two arguments, one of which it can call and one that can be expected, printed etc. This approach of defining a macro as a shallow wrapper around a function is quite common. It is also used in a couple of places in clojure.core Hope your attic lights up a little, Nils -- 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
Re: stack overflow vs scheme
Hi, the Scheme version of quicksort is not tail-recursive since append is called on the return value of the recursive calls. Thus, also in Scheme this eats up your stack. That your Scheme code can sort larger sequences simple means that your Scheme implementation has a larger stack than the JVM with standard settings. Basically, the only difference between Scheme and Clojure with respect to tail-recursion is that Scheme automatically optimizes the recursive call when it appears in a tail-call position whereas in Clojure you have to explicitly call recur (or trampoline for mutual recursion) if you want tail-call optimization. Since quicksort requires two recursive calls which then have to be combined it is not completely trivial to implement it in a tail- recursive, i.e. iterative, fashion. There is a general method which can be applied, namely continuation passing style (CPS), but it might look a little odd if you haven't seen it before. Basically, you use a variable holding a chain of closures which resemble the stack. I found a rather nice exposition in this blog post: http://www.enrico-franchi.org/2011/09/clojure-quicksort-in-continuation.html Cheers, Nils On Dec 1, 6:09 pm, john.holland jbholl...@gmail.com wrote: I was studying clojure for a while, and took a break to work on SICP in scheme. I found that they do numerous things that are against advice in Clojure having to do with the tail recursion. I got to thinking about that Clojure recur/loop stuff and wondered how you would do a quicksort with it. So I went to rosetta code and looked at what they had for scheme and for clojure. In scheme I can do a quicksort which makes two calls to itself and it can scale pretty high before running out of RAM. I went up to 1 sorting from worst (reversed) order to forward order. I do get stack overflows beyond that though. In clojure, the same algorithm produces the dreaded StackOverflow after 1000 values. I tried giving the JVM a gig of RAM, no help. Below are the (trvial) procedures. I understand that the advice in clojure is to use loop/recur etc, however, a big part of the charm for me of something like scheme is that I can write code that is a straightforward statement of a mathematical approach to the problem. Although quicksort is really simple, the idea of doing it with loop/recur baffles me. After a while with the scheme stuff clojure seems very complex and this, which seems like a fundamental issue, is not going well for it. Can anyone post a quicksort that doesn't give stack overflows in clojure? John scheme quicksort (define (quicksort l) (if (null? l) '() (append (quicksort (filter (lambda (x) ( (car l) x)) (cdr l)) ) (list (car l)) (quicksort (filter (lambda (x) ( (car l) x)) (cdr l)) =scheme utility to make data sets (define (nums x) (if ( x 0) '() (cons x (nums (- x 1) ==scheme call= (quicksort (nums 1)) ===clojure quicksort (defn qsort [[pivot xs]] (when pivot (let [smaller #( % pivot)] (lazy-cat (qsort (filter smaller xs)) [pivot] (qsort (remove smaller xs)) =clojure utility to make data sets (def nums (fn [lim] (loop [limx lim acc []] (if ( limx 0) acc (recur (- limx 1) (cons limx acc)) clojure call== (quicksort (nums 1)) -- 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
Agents vs. Actors
Hi, how do Clojure agents relate to Erlang actors? To gain some insights, I tried to implement Erlang style message passing between agents. The first version is just a very incomplete sketch (no mailbox, case instead of pattern matching ...), but already shows that it is quite easily doable: https://github.com/bertschi/clojure-stuff/blob/master/src/stuff/actors.clj The idea is that the agent holds a dispatch function which is then called by ! (send) with the message to be send. Somehow it resembles the way closures can be used to implement an object system. Thus, agents seem to be the functional analog of agents: Functional programming Object-oriented programming sequential closure object concurrent agent actors Another great design from Rich Hickey! Clojure is fun and gets better every day ... Thanks, Nils -- 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
Re: Agents vs. Actors
Hi Stuart, thanks for the info. I did not really think about some of these differences. Basically, it was just a fun exercise ... not (yet) useful for anything serious. On Dec 2, 10:14 pm, Stuart Sierra the.stuart.sie...@gmail.com wrote: how do Clojure agents relate to Erlang actors? There are several important differences: 1. Agents are designed for in-process communication only. Right, whereas Erlang actors are distributed. This was not so important for me at the moment. 2. Observing the state of an Agent does not require sending it a message. Good point, I must have forgotten that ... maybe this makes agents actually more general than actors? 3. Agents accept arbitrary functions instead of a predefined set of messages. That is true, but I was wondering whether it is possible to simulate Erlang style messages with this. In my sketch the state of an agent is a handler function which only accepts a limited set of messages. Seems to be a close fake of Erlang actors (and reading the state without sending a message as in 2. is not very useful since it only returns the handler function ... calling this function then acts as a send). -S Best, Nils -- 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
Re: stack overflow vs scheme
On Dec 2, 8:13 pm, john.holland jbholl...@gmail.com wrote: Thanks for all the replies. It seems to me that as general solutions to stack overflow, trampoline and recur are very valuable. I had gotten the mistaken idea that Scheme was somehow immune to the problem. My experiments in Scheme seemed to get to higher amounts of recursion before blowing up than my Clojure did, but they are both susceptible to it. Are there things like trampoline and recur in Scheme? In Lisp? Well yes, but they are not explicitly specified since Scheme automatically optimizes tail calls. Consider this example: (define (fact n) (if ( n 2) 1 (* n (fact (- n 1) This is not tail recursive and eventually blows the stack ... in Scheme and in Clojure. (define (fact-accu n res) (if ( n 2) res (fact-accu (- n 1) (* n res Here, the recursive call is in tail position and gets optimized by the Scheme compiler. In Clojure you would have to call recur instead, otherwise your stack grows. In Scheme this is not necessary since the optimization is always done if possible. Thus, there is no special syntactic marker, i.e. reserved word, for this. (Same holds for mutual recursion - trampoline). In Common Lisp the situation is somewhat unfortunate, since tail call optimization is implementation dependent. So, you cannot rely on it and therefore loop/tagbody etc are your friends there. Hope this helps, Nils John Holland -- 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
Re: Rebinding a recursive function
Hi Roman, as far as I understand, the Clojure compiler is doing some optimizations for recursive functions to save the variable lookup. This means that you have to explicitly write the recursive call as (#'fact (dec n)) if you want to dynamically rebind the function. Somehow this doesn't feel right for a dynamic language. Clojure 1.3, which cannot dynamically rebind variables unless they are explicitly marked as ^:dynamic, introduced with-redefs to solve this problem. In Clojure 1.3 you're example works as expected if you use with-redefs instead of binding in the definition of fact-with-logging. In case you can't use Clojure 1.3, you might be able to use the source code of with-redefs in order to achieve a similar effect in 1.2. Though, I haven't tested it. Best, Nils On Nov 30, 9:11 pm, Roman Perepelitsa roman.perepeli...@gmail.com wrote: Hello, I'm trying to intercept each call to a recursive function in order to insert logging. It works on the first invocation but not on others. What am I missing? (defn fact [n] (if ( n 2) 1 (* n (fact (dec n) ; Given function f, returns another function that ; does the same as f but also prints the arguments. (defn with-logging [f] (fn [ rest] (do (println (str rest)) (apply f rest ; Factorial that prints its argument on each call. (defn fact-with-logging [n] (binding [fact (with-logging fact)] (fact n))) ; This prints (5) but not (4)...(1). Why? (fact-with-logging 5) Roman. -- 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
Re: use namespace locally in a function
Clojure is a Lisp, so it should be possible to extend it yourself ... What about something like this? (defmacro locally-using Allows to use symbols from other namespace in the local scope of the macro body. Syntax: (locally-using [symbol*] :from namespace body) [symbols from ns-name body] (assert (= from :from) Wrong syntax ... delimiter :from missing or misplaced!) (let [local-vars (map (fn [sym] (symbol (str ns-name) (str sym))) symbols)] `(do (require '~ns-name) (symbol-macrolet [~@(interleave symbols local-vars)] ~@body which then let's you write: (locally-using [split] :from clojure.string (split Hello world # )) The above macro could probably be made smarter to only require the lib if it not already loaded and also unload when it is done in this case. But since you have to load the lib anyways to use it and qualified names do not clutter your current namespace, the above version seems to be good enough. Cheers, Nils On Nov 23, 4:40 am, Igor TN igor...@gmail.com wrote: Yes, I meant local context. In principle, this could help to avoid namespacing conflicts in certain cases. But not a big deal, just wondering if the language supports that. Apparently not. Cool with me. Thanks everybody! On Nov 22, 6:59 pm, Alex Baranosky alexander.barano...@gmail.com wrote: Looks like he'd like to make a namespace available *only* in a local context, which some languages support, like Scala, for one. I never have a need for that, really. -- 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
Re: deprecating butlast?
Hi, you're right that drop-last is more general than butlast. So why does butlast exist at all? I would say, that it is there for a very good reasons. It solves a common problem, namely to drop the last element of a sequence and reads better in this case than the equivalent idiom using drop-last. Thus, it is a perfect example for a useful abstraction and capturing common abstractions should be the main reason for defining functions (macros) in the first place. Obviously, any function (macro) could always be replaced by its definition, so it has to justify its existence by being reusable and improving readability. This also applies if it only captures a very special use case as long as it is common enough. I would say that butlast is well justified according to these criteria. Best, Nils On Nov 22, 12:54 pm, Daniel Janus nath...@gmail.com wrote: Hi, Why keep both butlast and drop-last in clojure.core? The latter has the advantage that it's lazy and can drop off more than one element from the end of a seq. In contrast, I can't think of any advantage of butlast, except that it seems to be slightly (ca 20%) faster than (doall (drop-last x)). Wrapping drop-last in a doall should not be normally necessary, though. Should butlast be deprecated? Thanks, Daniel -- 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
Re: Probabilistic programming in clojure
Hi Jeff, good idea to move this over to clojure 1.3. I have just included your patch. On Nov 20, 5:32 am, Jeff Rose ros...@gmail.com wrote: Cool! I experimented a little bit with Church a while back, but having something like this in Clojure could be really interesting. I don't have much experience with sampling, but if I understand it correctly, your grass-is-wet demo is defining a belief network where each sample taken represents the complete state of the graph, or just the final outcome? What does a sample look like? It would be great if we could use this kind of generative model to create chord sequences, melodies, and rhythms for Overtone. I don't know what kinds of choice points would be appropriate, or if we could train them based on a database of existing progressions? The grass-is-wet demo indeed specifies a belief network. In contrast to Church, the definition of the model, conditioning on observations and specifying the output variables is all done in one path. This works exactly like the probability monad in clojure.contrib. Thus, each sample corresponds to an outcome of the output variables, i.e. rain in the example. Since the model is conditioned on grass-is-wet = true, using m-zero of the monad implements rejection sampling, you obtain samples of the posterior distribution p(rain | grass-is-wet = true). In principle it should be possible to use it for generative models of music. Since I'm not an expert in this area, I don't know which kind of models and probability distributions are useful to describe musical structure. Let me know if you have an idea, I would be happy to help putting it into clojure. Best, Nils -Jeff On Nov 18, 12:57 am, Nils Bertschinger nils.bertschin...@googlemail.com wrote: Hi everyone, inspired by the bher compiler for the probabilistic scheme dialect MIT Church, I have implemented a version of the probability monad which uses Metropolis Hastings to draw samples from runs of monadic programs. You can find the code on github:https://github.com/bertschi/ProbClojureNice. The monadic version is more a proof of principle and not very fast. It might nevertheless be useful, e.g. for educational purposes. Have a look and decide for yourself ... For the future, I'm working on a different approach to embed probabilistic operations into clojure which scales better and allows to run somewhat larger models. Any comments and feedback are welcome. Best, Nils -- 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
Re: Probabilistic programming in clojure
Hi Julius, good catch, I don't know how I missed that??? Just uploaded a fix ... should work now. Nils On Nov 20, 5:58 pm, Julius Seporaitis jul...@seporaitis.net wrote: Hello guys, I would like to try out this library, but ran into a problem with Clojure 1.3, 'lein repl' throws an exception, when: *user= (use 'probabilistic-clojure.monadic.demos)* *user= (test-mixture mixture-mem) * *Trying to find valid trace ...* *Starting MH-sampling.* *IllegalArgumentException No value supplied for key: 0.7 clojure.lang.PersistentHashMap.createWithCheck (PersistentHashMap.java:89)* I am a total beginner with Clojure, if you could provide a at least a hint of how to resolve this - I'd appreciate it. P.S. I am using the 1.3 branch by Jeff, that works with Leiningen. Thanks! - Julius -- 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
Re: Probabilistic programming in clojure
On Nov 18, 8:05 am, Konrad Hinsen googlegro...@khinsen.fastmail.net wrote: --On 17 novembre 2011 15:09:11 -0800 Nils Bertschinger nils.bertschin...@googlemail.com wrote: The two approaches are somewhat complementary to each other. Your monad does exact inference on discrete distributions by running through all possibilities. Mine is sampling based and does approximate inference using MCMC. I tried that approach as well: https://github.com/richhickey/clojure-contrib/blob/master/src/main/cl... but I never used it much because for my own applications, exact inference was very doable. I'll check out yours for comparison! Just checked your implementation, the stream approach is indeed quite nice to thread random numbers through programs. It seems that I handle downstream conditioning somewhat different. The stream can basically be filtered to implement rejection sampling, whereas I thread a database state through the program to record all random choices (as well as their probability) that have been taken. That way conditioning does not have to be based on rejection, but is simply accounted for by including the probability of the conditioned value. Then I can propose a change to this database store, re-run the program and implement Metropolis Hastings sampling on top of this, i.e. test whether the change increased the probability of the random decisions taken throughout the program and either accept or reject it accordingly. Your stream approach can probably be nicely extended to particle filters. I'll think about that ... Nils Konrad. -- 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
Probabilistic programming in clojure
Hi everyone, inspired by the bher compiler for the probabilistic scheme dialect MIT Church, I have implemented a version of the probability monad which uses Metropolis Hastings to draw samples from runs of monadic programs. You can find the code on github: https://github.com/bertschi/ProbClojureNice. The monadic version is more a proof of principle and not very fast. It might nevertheless be useful, e.g. for educational purposes. Have a look and decide for yourself ... For the future, I'm working on a different approach to embed probabilistic operations into clojure which scales better and allows to run somewhat larger models. Any comments and feedback are welcome. Best, Nils -- 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
Re: Probabilistic programming in clojure
Hi Konrad, thanks for the link. I know your very nice library and actually use clojure.contrib.monads to implement my probability monad. The two approaches are somewhat complementary to each other. Your monad does exact inference on discrete distributions by running through all possibilities. Mine is sampling based and does approximate inference using MCMC. This makes it feasible to simulate larger discrete models and also continuous distributions can easily be incorporated. In the demos section you can find a Gaussian mixture model demonstrating these features. Nils On Nov 17, 9:58 pm, Konrad Hinsen googlegro...@khinsen.fastmail.net wrote: There's also this one in clojure-contrib (old, not yet moved to the new contrib collection): https://github.com/richhickey/clojure-contrib/tree/master/src/main/cl... Konrad. -- 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
Re: Eval in future ... Bug or feature?
On Sep 3, 2:35 am, Brian Goslinga quickbasicg...@gmail.com wrote: The future is probably executing in a different thread, so the dynamic binding of *ns* probably isn't the user namespace. Thanks Brian. That's exactly what happens: user (future *ns*) #core$future_call$reify__5496@489a44f1: :pending user (deref *1) #Namespace clojure.core Thus, I have to either re-bind *ns* or use one of the bound-fn forms: user (future (binding [*ns* (the-ns 'user)] (eval '(my-inc 1 #core$future_call$reify__5496@eaa4c7c: :pending user (deref *1) 2 user (pmap (bound-fn* eval) '((my-inc 1) (my-inc 2))) (2 3) Thanks again, Nils -- 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
Eval in future ... Bug or feature?
Hi everyone, it appears that eval works differently when used inside a future. The following example REPL session shows what I mean: user (clojure-version) 1.2.0-master-SNAPSHOT user (defn my-inc [x] (+ x 1)) #'user/my-inc user (eval '(my-inc 1)) 2 user (future (eval '(my-inc 1))) #core$future_call$reify__5496@18c92d9: :pending user (deref *1) java.lang.Exception: Unable to resolve symbol: my-inc in this context (NO_SOURCE_FILE:1) [Thrown class java.util.concurrent.ExecutionException] I found this rather strange. Does anyone know why this happens and whether it is actually intended? Is it a bug or a feature ;-). Best, Nils -- 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
