core.logic: question on ordering in conjunction
I wrote this goal: (use 'clojure.core.logic) (use 'clojure.core.logic.protocols) (defn pluso [t1 t2 s] (fn goal [a] (let [args (map (partial walk a) [t1 t2 s]) fresh? (map lvar? args) ground? (map not fresh?) [t1 t2 s] args] (cond (= [true true true ] ground?) (if (= s (+ t1 t2)) a nil) (= [true true false] ground?) (unify a s (+ t1 t2)) (= [true false true ] ground?) (unify a t2 (- s t1)) (= [false true true ] ground?) (unify a t1 (- s t2)) :else a ;; Returning the substitution map will mark this goal as successful ;; while it is neither successful nor failed. The fresh variables ;; might be ground later. When I run this query I get (_0) while I'm expecting (3). The root of the problem is the returning of the substitution map if more than one variable is not ground. (run* [q] (fresh [a] (pluso q 4 a) (== a 7))) I've tried returning a choice but this leads to an endless loop. Is it at all possible to somehow adapt the goal to await the grounding of the a-variable? What if the fresh variables are never ground? -- -- 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.
Re: core.logic: question on ordering in conjunction
How does one recognize a relational or non-relational goal? Thanks for the fd example. On Sunday, June 30, 2013 7:34:58 PM UTC+2, Norman Richards wrote: What you are trying to do is non-relational, and will only work when you put the non-relational pluso at the end. You can obviously use the finite domain extensions to core.logic to accomplish this: (defn fd-pluso [t1 t2 s] (fd/eq (= s (+ t1 t2 (run* [q] (fresh [a] (fd/in q a (fd/interval Integer/MAX_VALUE)) (fd-pluso q 4 a) (== a 7))) = (3) I don't know how you achieve this result in core.logic without the finite domain support. -- -- 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.
= and byte arrays
Given two byte arrays that have the same content (value) the code below runs without errors: (def ba1 (...)) (def ba2 (...)) (assert (not= ba1 ba2)) (assert (= (String. ba1) (String ba2))) Is this as expected? -- 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: Complex type in clojure
On 8 jun, 05:47, Daniel doubleagen...@gmail.com wrote: These notation arguments are compelling. I'm not convinced. The notation would only work for literals, and how often would one write literal complex numbers? For non-literals the notation would need to support this: (* (my-complicated-algo x)+(my-other-complicated-algo y)i (another- algo z)i) This is no issue at all without this notation: (complex-times [(my-complicated-algo x) (my-other-complicated-algo y)] [0 (another-algo z)]) Implementing this notation would obviously require a serious overhaul of clojure for a nice-to-have feature. -- 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: Complex type in clojure
On 8 jun, 16:38, Mike Meyer mwm-keyword-googlegroups. 620...@mired.org wrote: Why? It isn't supported for rationals or exponents. Or are you claiming that because we support 3/4 we should also support (* (my-complicated-algo val)/(my-other-complicated-algo exp) 1/(another-complicated-algo exp2)) with similar problems because we support 1e3? mike What would (Math/pow (Math/E (* 2/5 2 Math/PI i))) return? -- 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: Complex type in clojure
On 8 jun, 19:43, ataggart alex.tagg...@gmail.com wrote: On Jun 8, 6:33 am, Steven Devijver steven.devij...@gmail.com wrote: On 8 jun, 05:47, Daniel doubleagen...@gmail.com wrote: These notation arguments are compelling. I'm not convinced. The notation would only work for literals Correct. For non-literals the notation would need to support this: (* (my-complicated-algo x)+(my-other-complicated-algo y)i (another- algo z)i) You're conflating notation with operation. This is no issue at all without this notation: (complex-times [(my-complicated-algo x) (my-other-complicated-algo y)] [0 (another-algo z)]) The point here is not simply to add a literal notation, but to integrate complex type handling into the math functions. Bifurcating the math functions is a horrible idea. Implementing this notation would obviously require a serious overhaul of clojure for a nice-to-have feature. Augmenting the math functions to support complex numbers requires a serious overhaul. Augmenting the reader to handle the notation is trivial, so I'm not clear on why you're obsessing about it. It's a mischaracterization to say I'm obsessed about this. I think this whole idea is an waste of time and effort with no valuable outcome. Color me skeptical. -- 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: Complex type in clojure
For what it's worth, I found that working with complex numbers in clojure doesn't require specialist types or notation at all: (defn complex-times [[a_re a_im] [b_re b_im]] [(- (* a_re b_re) (* a_im b_im)) (+ (* a_re b_im) (* a_im b_re))]) (defn complex-plus [[a_re a_im] [b_re b_im]] [(+ a_re b_re) (+ a_im b_im)]) (defn complex-minus [[a_re a_im] [b_re b_im]] [(- a_re b_re) (- a_im b_im)]) (defn complex-abs [[re im]] (Math/hypot re im)) (prn (complex-abs (complex-plus [1.5 1] (complex-times [1 -2] [2 -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
Re: new Clojure Compiler...
On 17 mei, 08:48, Fabio Kaminski fabiokamin...@gmail.com wrote: first that dinamic languages are better for developers, but you loose some performance compared to typed languages.. and jvm was created with types in mind.. so right now clojure data structures are implemented in java and typed, when you get it in the clojure runtime its boxed already. theres some good approaches for dinamic languages like trace-jits(notably the new mozilla-javascript and luajit) .. but we are not there yet.. (JSR's was created as lazy sequences .. rsrs) This is the typical confusion about dynamic languages. Actually, Clojure is not a dynamic language, it's a dynamically typed language. Dynamic typing on the JVM generally doesn't suffer from a performance impact, unless you're in the camp of people who believe reflection is slow. Real dynamic languages like Ruby or Groovy do suffer from a gigantic performance impact due to the feature that distinguish dynamic languages from other languages: the meta protocol. In Ruby and Groovy a method call is never really a method call, it's a message that's sent through the meta protocol. It's this feature that gives you the findByYourGrandMothersBirthDate() dynamic methods in Ruby on Rails and Grails. These are not calls to methods at all, they are calls that get parsed and converted into database query statements. Clojure does not have a meta protocol and thus is not a dynamic language, and thus does not have the associated performance impact. You might have heard about Groovy++ which is branded as the new new thing these days. Groovy++ is simply Groovy without the meta protocol, hence fast Groovy. -- 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: Which git version for cells?
On 17 mei, 19:25, Eric Schulte schulte.e...@gmail.com wrote: Hi Steven, I recently put together a propagator/cell system using Clojure's actors/watchers. The code for implementing a concurrent propagator system actually came out to a little less than a single page. Take a look at the following for the full implementation. http://gist.github.com/403987 Here's an example usage taking square roots using the Heron approximation. http://gist.github.com/403990 This was all done with the following versions -- take from the lein project.clj file. --8---cut here---start-8--- (defproject propagator 1.0.0-SNAPSHOT :description Concurrent propagator system :dependencies [[org.clojure/clojure 1.1.0-alpha-SNAPSHOT] [org.clojure/clojure-contrib 1.0-SNAPSHOT] [vijual 0.1.0-SNAPSHOT] [ring 0.2.0]] :dev-dependencies [[leiningen/lein-swank 1.0.0-SNAPSHOT]]) --8---cut here---end---8--- Best -- Eric Hey Eric, This looks like a very tight implementation indeed! I'll take it for a spin soon. Thanks Steven -- 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
Which git version for cells?
I'm experimenting with cells in clojure and am currently using the lazy branch for this. However, I'm getting some strange behavior. So my question is: which branch should I be using if I want to test- drive the watcher feature? Thanks -- 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
Leaky configuration with multi-methods
Hey,
I have this multi-method setup:
(defmulti dsl-walk :Rule)
(defmulti component-constructor :Component)
(defmethod dsl-walk :SymbolPlus [r]
(let [children (map dsl-walk (:recurrent r))]
(apply component-constructor (list {:Component (keyword (:symbol
r)) :children children}
(defmethod dsl-walk :KeywordAnyPlus [r]
(apply component-constructor (list {:Component (apply (:resolver r)
(list (:keyword r))) :name (:keyword r) :values (:any-section r)})))
(defmethod dsl-walk :KeywordArgsPlus [r]
(apply component-constructor (list {:Component (apply (:resolver r)
(list (:keyword r))) :name (:keyword r) :args (:args-section r)})))
For the :KeywordAnyPlus and :KeywordArgsPlus method defs I need to
provide a resolver function. My concern is how to pass in this
function without leaking implementation details onto the callers the
multi-method?
For now I've added the function to the data structure that I pass to
the dsl-walk methods using postwalk. I find this too crude.
I've tried using declare to add a namespace-local function and then
have that function assigned by the functions that use dsl-walk but
haven't found a way to assign a value to a declared var from another
namespace.
I can't add a second argument to the dsl-walk methods since dsl-walk
is being called recursively on a data structure.
What's the best approach to pass in a function from a calling
namespace without leaking implementation details?
Thanks
--
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: Impact of gen-class on clojure-ness
On 29 mrt, 09:43, Jarkko Oranen chous...@gmail.com wrote: Interfaces are good, but defining your own is mainly reserved for Java interop. You should strive to use plain old untyped data structures for your data, ie. just put things in maps, vectors, sets andl lists. Write (pure) functions to transform the data, and some logic to handle program state. Try to keep a clear separation between state-handling or interactive code and data-handling logic. Also make use of Clojure's sequence abstraction. The core libraries have many functions for processing sequences. The core abstraction in Clojure is a function. There is a feature called protocols in git master that will become the Clojure way of defining interfaces, but even if it is a protocol, the interface is simply a collection of functions. If you're used to object oriented programming, you need to invert your thought process from What methods does this object have? to What data can this function process? Thanks for your reply. I understand there are more clojure-ish ways then to use Java interfaces, but I take from your answer that using Java interface with gen-class won't introduce technical issues. -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
