Re: Benefits to partial functions.

[Alex Engelberg]

All functions returned by a given arity of partial or comp are of the same
Java class under the hood, whereas defining an anonymous function always
generates a new class, and I've heard that fewer classes can result in
better performance from a JIT perspective. But I'm just speculating and
haven't actually run the benchmarks. So, [citation needed].

>From a more practical perspective: I always prefer to give my anonymous
functions names (e.g. `(fn foo [x])`, not `(fn [x])`), so that the stack
traces are a bit more self-explanatory, but partial and comp don't let you
do that. Although sometimes the added readability of a higher-order
function outweighs that concern.

On Sun, Oct 20, 2019 at 2:55 PM John D. Hume 
wrote:

> It's been a long time since I looked at this, but as of a few years ago,
> the biggest noticeable performance detriment of comp or partial was likely
> to come if you pass enough args to hit a "& args" overload, which requires
> creating a fresh object array at each call, when the underlying function
> being called has a non-"& args" arity.
>
> On one application I worked on, we preferred defining #(anonymous ...)
> functions to some uses of higher order functions to avoid excessive
> garbage-creation in some hot spots.
>
> This assumes you don't need primitive type-hint-level optimization.
>
> I wouldn't recommend sacrificing any clarity unless you've profiled and
> found a real issue.
>
> definition of partial:
>
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2614
>
> definition of comp:
>
> https://github.com/clojure/clojure/blob/master/src/clj/clojure/core.clj#L2557
>
>
> On Sun, Oct 20, 2019, 3:25 PM david hoyt  wrote:
>
>> Is there a performance benefit (or detriment) to creating partial
>> functions? Other than the potential reduction of complexity, is there a
>> difference between using partial & comp and defining new functions?
>>
>> --
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/clojure/146f2a73-9887-4eba-89c6-815eed6841b1%40googlegroups.com
>> .
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/CAKK7-VLE_TPdjBuf6g8n0hVLaiMeibS63wJ8UqGDKD1qGZ4T2A%40mail.gmail.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CAMvaFAXa6Qhch%2B%2B-OCTVz399GCAiHJxxNM6VM%3Dak3hjVzkB1gw%40mail.gmail.com.

[JOB] Software Engineer | Amperity | Seattle

[Alex Engelberg]

Amperity is a Clojure-powered startup with a lean but mean team of 18 
engineers. We're looking to add talented engineers to help build a 
disruptive SaaS business to revolutionize marketing as we know it today. 
Our product is almost 100% Clojure, and we use Clojure every day for:

   - *services* - Scalable microservices that serve internal and public 
   APIs. Technologies include Finagle, Aleph, Kafka, Riemann, and Clojure Spec.
   - *UIs* - Building a single-page UI on top of a complex backend using 
   pure ClojureScript. Technologies include Reagent, re-frame, and Figwheel.
   - *data science* - The secret sauce of the product. We consult academic 
   experts in the data science / machine learning community to refine our 
   cutting-edge entity resolution algorithms. Technologies include Spark and 
   Accumulo.
   - *tooling* - We don't mess with success when tools already exist to get 
   the job done, but sometimes we have to craft artisanal tooling to fill the 
   gaps. This has resulted in multiple open-source libraries we continue to 
   maintain, including lein-monolith 
   , greenlight 
   , and envoy 
   .
   
We are primarily looking for local (Seattle, WA) full-time engineers but 
are open to remote folks. Check out our Careers 
 page or homepage 
 to learn more about what we do!

--Alex

-- 
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/d/optout.

Re: Future

[Alex Engelberg]

Not sure what's going on with shutdown-agents, but you could call (run!
deref ...) to wait for all the futures to complete.

On Sat, May 19, 2018 at 3:29 PM Renata Soares 
wrote:

> Hello,
>
> I am using future this way:
>
> (doall (map #(future ()  (range 1 max-size))
>
> When the max-size is small like around 6, if I don't print (println (doall
> (map #(future ()  (range 1 max-size))), the
> result  becomes empty
>
> (Without print)
>
> renata@renata:~/$ lein run
> ranking  {}
>
> (With print)
> renata@renata:~/$$ lein run
> (#object[clojure.core$future_call$reify__6962 0x6492fab5 {:status :ready,
> :val {:2 0, :4 0.0, :5 0, :1 2.5}}]
> #object[clojure.core$future_call$reify__6962 0x2c532cd8 {:status :ready,
> :val {:2 0}}] #object[clojure.core$future_call$reify__6962 0x294e5088
> {:status :ready, :val {:2 0, :4 0.0, :5 0, :1 2.5, :3 1.0}}]
> #object[clojure.core$future_call$reify__6962 0x51972dc7 {:status :ready,
> :val {:2 0, :4 0.0}}] #object[clojure.core$future_call$reify__6962
> 0x3700ec9c {:status :ready, :val {:2 0, :4 0.0, :5 0}}])
> ranking  {"1":2.5,"3":1.0,"5":0,"4":0.0,"2":0}
>
> I am using (shutdown-agents) after the doall...
>
> Any ideas why? I think it is because the futures aren't ready when
> (shutdown-agents) executes.
>
> (When the max-size is big, run normally)
>
> There is a way that I can wait for print the result until all futures are
> ready?
>
> 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
> ---
> 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/d/optout.
>

-- 
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/d/optout.

Re: Generating a deck of cards in Clojure using generator functions (a la Python)

[Alex Engelberg]

I originally abandoned clj-generators because it introduces significant
performance overhead (and an extra thread), which I think makes it
unrealistic for generating lazy sequences in practice.

Perhaps switching to dar.async would remove the overhead:

https://github.com/dar-clojure/async

On Tue, Mar 14, 2017 at 10:59 PM Alan Thompson  wrote:

> A recent post to StackOverflow
> <http://stackoverflow.com/questions/42798706/clojure-clojurescript-elegant-way-to-generate-a-deck-of-cards/42801711#42801711>
> asked for clarification on different ways of generating a deck of cards.
> The OP had used nested `for` with `flatten` and `map-indexed` but thought
> there must be a better (clearer & more concise) solution.  In addition to
> the first two solutions offered, this problem also shows an example of when
> Python-style *generator functions* with a *yield* statement may also be
> considered. Pasted below is the example:
>
> -
> For a third take on this problem, you can use the generator/yield style of
> programming popular in Python. This solution makes use of the *lazy-gen* &
> *yield* combination from the Tupelo library
> <https://github.com/cloojure/tupelo#generator-functions-for-lazy-sequences-a-la-python>
> :
>
>
> (ns tst.clj.core
>   (:use clojure.test tupelo.test)
>   (:require  [tupelo.core :as t]  ))
> (t/refer-tupelo)
>
> (defn new-deck []
>   (lazy-gen
> (let [id (atom 0)]
>   (doseq [suit [:spade :heart :diamond :club]]
> (doseq [rank [:2 :3 :4 :5 :6 :7 :8 :9 :10 :jack :queen :king :ace]
> ]
>   (yield {:id (swap! id inc) :suit suit :rank rank}))
>
> (pprint (new-deck))
>
> ({:suit :spade, :rank :2, :id 1}
>  {:suit :spade, :rank :3, :id 2}
>  {:suit :spade, :rank :4, :id 3}
>  {:suit :spade, :rank :5, :id 4}
>  {:suit :spade, :rank :6, :id 5}
>  {:suit :spade, :rank :7, :id 6}
>  {:suit :spade, :rank :8, :id 7}
>  {:suit :spade, :rank :9, :id 8}
>  {:suit :spade, :rank :10, :id 9}
>  {:suit :spade, :rank :jack, :id 10}
>  {:suit :spade, :rank :queen, :id 11}
>  {:suit :spade, :rank :king, :id 12}
>  {:suit :spade, :rank :ace, :id 13}
>  {:suit :heart, :rank :2, :id 14}
>  {:suit :heart, :rank :3, :id 15}
>  {:suit :heart, :rank :4, :id 16}
>  {:suit :heart, :rank :5, :id 17}
> 
>  {:suit :club, :rank :10, :id 48}
>  {:suit :club, :rank :jack, :id 49}
>  {:suit :club, :rank :queen, :id 50}
>  {:suit :club, :rank :king, :id 51}
>  {:suit :club, :rank :ace, :id 52})
>
> I just had to use keywords for the card names since using :rank 13 for the
> ace (or is it the king?) is just wrong...(shudder)...on so many levels! ;)
> Note that it is legal for a keyword in Clojure to consist of only digits.
>
> Since *yield* is putting the individual items on the output queue, we
> don't need to return a sequence from for and can just use doseq. Also, we
> don't need to worry about a multi-variate for, nor about using flatten,
> concat, or mapcat constructs. Use of the atom for id is as simple as it
> gets, although you could build the whole thing out of loop/recur instead of
> the atom & 2 doseq forms if you really wanted to be "pure".
>
> Under the covers *lazy-gen/yield* uses core.async to create an output
> stream with a default buffer size of 32 (modeled after lazy chunking
> in clojure.core).
>
> While for and map-indexed solutions work fine for this example, sometimes
> it may be clearer to the reader to be extra explicit about the looping
> constructs, etc. Also, if there were other operations in the inner loop
> before & after the yield statement, it might be awkward to force the
> solution into a map or for style solution.
>
> Enjoy!
>
> Alan
>
> P.S.  I noticed after searching that Alex Engelberg worked on something
> similar a few years ago. This version is slightly different from his
> (hopefully improved!), although I did switch some symbols to gensyms after
> seeing his implementation.  :)
>
> P.P.S.  Before the purists complain about the use of mutable state &
> imperative loops, please remember that *for some problems* (not all!)
> this may yield a simpler solution with fewer mental stack frames required.
> Also, the solution is a pure function overall as seen from the outside,
> since it returns a non-side-effecting lazy-sequence, and neither the state
> atom nor the imperative loops escape the function body. This is similar to
> the implementation of many functions in clojure.core itself.
>
>
> --
> 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

Re: [ANN] Instaparse 1.4.4

[Alex Engelberg]

Hi Jeaye,

1. That's indeed a mistaken breakage, I will fix it. Note that specifically
the java.net.URL input is what's not properly handled, so if you call (str
(io/resource "...")) that will still work as expected.

2. That's also a bug, due to how defparser quotes all of its arguments and
tries to use them as arguments to insta/parser. I will fix it, and add more
thorough tests for the macro.

To answer your more general question: I don't think Clojure users of
Instaparse should really have to think about defparser, since I think most
JVM use cases don't suffer from the small extra one-time startup cost. I
made it primarily with ClojureScript in mind, since being able to now slurp
the grammar adds some power that's non-trivial to implement otherwise. But
I made it available to both clj and cljs for completeness and
cross-compatibility.

Thanks for the reports.
--Alex

On Sat, Dec 24, 2016 at 3:13 PM, Jeaye  wrote:

> This is great to see; instaparse is crucial for some of my projects and I
> appreciate the ongoing development.
>
> I've noticed two issues with 1.4.4 which I want to run by you:
>
> 1. insta/parser has a breaking change, in that it no longer accepts
> resources directly
>
>   I can work around this easily by slurping before hand, but this may've
> been an accidental breakage.
>
> 2. insta/defparser doesn't support the same optional parameters as
> insta/parser
>
>   Specifically, I've found that it doesn't like when I specify
> :auto-whitespace, which is a feature on which I rely heavily for my grammar.
>
> Finally, given the possible performance benefits, do you recommend
> everyone (Clojure and ClojureScript) prefer defparser, where possible?
>
> Thanks!
>
> On Fri, Dec 23, 2016 at 04:52:12PM -0800, Mark Engelberg wrote:
> > Instaparse is a library for generating parsers from context-free
> grammars.
> > https://github.com/engelberg/instaparse
> >
> > The big news for this release is that Alex Engelberg has combined the
> > Clojure version with the Clojurescript version of instaparse (initiated
> by
> > Lucas Bradstreet in 2014) so that moving forward, we can maintain both
> > versions as part of the same codebase.  Instaparse leverages a number of
> > Clojure interfaces and subtle features that differ between Clojure and
> > Clojurescript, so merging the ports was a significant effort.
> >
> > Also, to achieve backwards compatibility, Alex wrote the cljsee leiningen
> > plugin which splits cljc files into clj and cljs files for compatibility
> > with Clojure 1.5 and 1.6.  Check out cljsee if you are interested in
> > maintaining backwards compatibility in your own cljc-based projects.  (
> > https://github.com/aengelberg/cljsee)
> >
> > The one new feature is a defparser macro, especially relevant to the
> > Clojurescript port because it makes it possible to build the parser at
> > compile time so the Clojurescript code will execute more quickly.
> >
> > Other than that one addition, the behavior should be identical to the
> prior
> > release.
> >
> > --
> > 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/d/optout.
>
> --
> 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/d/optout.
>

-- 
You received this message because y

Re: finding clojure functions from the mangled names

[Alex Engelberg]

If you're seeing "fn_123", it's probably coming from an anonymous function.
Giving those functions a name with the (fn my-name [] ...) syntax will make
the stack trace a little easier to decipher:

user=> ((fn [] (/ 1 0)))

ArithmeticException Divide by zero  clojure.lang.Numbers.divide
(Numbers.java:158)

user=> (pst)

ArithmeticException Divide by zero
clojure.lang.Numbers.divide (Numbers.java:158)
clojure.lang.Numbers.divide (Numbers.java:3808)
user/eval20851/fn--20852 (form-init8836862334241327650.clj:1)
​...​

nil
user=> ((fn my-fn-with-a-name [] (/ 1 0))

ArithmeticException Divide by zero  clojure.lang.Numbers.divide
(Numbers.java:158)
user=> (pst)
ArithmeticException Divide by zero
clojure.lang.Numbers.divide (Numbers.java:158)
clojure.lang.Numbers.divide (Numbers.java:3808)
user/eval20857/my-fn-with-a-name--20858 (form-init8836862334241327650.clj:1)
​...​

nil

On Fri, Dec 9, 2016 at 3:00 PM, Brian Craft  wrote:

> Trying to profile some code, and the stack traces look like
>
> clojure.something0
>   clojure.something1
>clojure.something2
>  
>   clojure.something100
>  foo$fn_1000$fn_1002$fn_10003.invoke()
>
>
> How can I figure out what that last function is? I can access the symbol
> from the repl, but no idea how to connect it to my code.
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: Reader macro not ignoring form?

[Alex Engelberg]

This appears to be a more general issue that can be reproduced by sending
" " as a single command to the REPL. I was able
to get similar behavior by sending in other types of malformed expressions.
When I hit enter the second time, the valid form came through.

user=> ​​:) ​1​
​
RuntimeException Invalid token: :  clojure.lang.Util.runtimeException
(Util.java:221)
RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException
(Util.java:221)
user=>
​1​
user=> :a/ ​:result​

RuntimeException Invalid token: :a/  clojure.lang.Util.runtimeException
(Util.java:221)
user=>
​:result


On Sat, Sep 17, 2016 at 7:14 PM, craig worrall <
craig.worr...@transacumen.com> wrote:

>
> nREPL server started on port 37885 on host 127.0.0.1 - nrepl://
> 127.0.0.1:37885
> REPL-y 0.3.7, nREPL 0.2.12
> Clojure 1.9.0-alpha11
> OpenJDK 64-Bit Server VM 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14
> Docs: (doc function-name-here)
>   (find-doc "part-of-name-here")
>   Source: (source function-name-here)
>  Javadoc: (javadoc java-object-or-class-here)
> Exit: Control+D or (exit) or (quit)
>  Results: Stored in vars *1, *2, *3, an exception in *e
>
> user=> (::foo/bar {})
>
> RuntimeException Invalid token: ::foo/bar  clojure.lang.Util.runtimeException
> (Util.java:221)
> RuntimeException Unmatched delimiter: )  clojure.lang.Util.runtimeException
> (Util.java:221)
> user=> #_(::foo/bar {})
> {}
> user=>
>
> but:
>
> nREPL server started on port 39659 on host 127.0.0.1 - nrepl://
> 127.0.0.1:39659
> REPL-y 0.3.7, nREPL 0.2.12
> Clojure 1.9.0-alpha11
> OpenJDK 64-Bit Server VM 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14
> Docs: (doc function-name-here)
>   (find-doc "part-of-name-here")
>   Source: (source function-name-here)
>  Javadoc: (javadoc java-object-or-class-here)
> Exit: Control+D or (exit) or (quit)
>  Results: Stored in vars *1, *2, *3, an exception in *e
>
> user=> #_(::foo/bar {})
>
> user=>
>
>
>
> Craig
>
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

[ANN] cljsee 0.1.0

[Alex Engelberg]

https://github.com/aengelberg/cljsee

Cljsee is a Leiningen plugin that applies the idea of cljx to the new cljc 
reader conditional format. In other words, as a build step, it parses .cljc 
files and outputs .clj and/or .cljs files with only the relevant code. The 
purpose of this library is to enable library maintainers to write cljc 
code, and expressively target multiple platforms from a single file, but 
maintain compatibility with Clojure 1.6 and below in which reader 
conditionals are not supported.

--Alex

-- 
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/d/optout.

Re: finding optimal pairs/triplets

[Alex Engelberg]

Loco's constraints and expressions only work on integers, so unfortunately 
$nth can't handle maps in a list. $nth takes either a list of Loco 
expressions or a list of integers. To get the nth player level, you could 
try:
($nth (map :level players) [:p 0 0])

Also, I should mention that all Loco constraints (anything beginning with 
$, really) don't really return any values of substance, they just return a 
map of constraint data to be used by other constraints and the solving 
function. So your usage of ":level" is not going to behave how you expect 
(it will just return "nil" because the return value of $nth has no :level 
key).

Let me know how my alternative solution works for you.

Thanks!
--Alex

On Tuesday, October 6, 2015 at 7:22:55 AM UTC-7, Kurt Sys wrote:
>
>
> So, the basic idea is to construct a matrix like this:
>  spot1  spot2  spot3
> team1  5  0  -1
> team2  4  1  -1 
> ...
>
> With the 'spots' the spaces to fill in for each team. There are max 3 
> spots/team. If a spot is not used, -1 should be put. If it is used, I put 
> the number of the player (index in the defined vector). For example, with a 
> very small player vector:
> (def players [{:level 3} {:level 4} {:level 7} {:level 1}])
>
>
> The problems I'm facing so far:
>
> 1/ using $distinct to make sure each player is only assigned one spot on 
> one team.
> The value of -1 can be used more than once, because it's used as filler 
> where no player is assigned.
>
> (defn base-model [players]
>   (concat (for [team (range (quot (count players) 2)), spot (range 3)] 
> ($in [:p team spot] (range -1 (count players)) 
>  
> (def all (for [team (range (quot (count players) 2)), spot (range 3)] 
>   [:p team spot]))
>
> (solutions (conj (base-model ps) ($distinct all) ))
>
>
> doesn't give any solutions, obviously: there are always more possible 
> spots to fill than there are players. A work-around would be to add more 
> negative numbers as 'fillers', and adding some other constraints so that at 
> least two of the three spots per team are positive. I'll make sure the 
> vector is sorted anyway, on level first and experience second (with the 
> player having the highest number in the front of each team, as captain), so 
> that might be rather easy to do. 
> But it feels rather hacky.
>
> 2/ getting player data with $nth, so constraints based on player 
> characteristics can be added. 
> For example, if I want player of team 1 on slot 1 having a level of more 
> than 2, I'd expect something like this to work:
> (solutions (conj (base-model ps) ($> (:level ($nth players [:p 0 0])) 2)  
> ))
> which translates to me: take player on index given by [:p 0 0] from 
> 'players', get the level from that player and check if it's higher than 2. 
> This, however, does not work:
> IllegalArgumentException No method in multimethod '->choco*' for dispatch 
> value: null  clojure.lang.MultiFn.getFn (MultiFn.java:156)
> I clearly misunderstand how $nth (or how loco in general) works. How I can 
> use my player characteristics (the vector of player data maps) for adding 
> constraints?
>
> Thx, qsys
>
>
>
>
> Op dinsdag 6 oktober 2015 12:10:23 UTC+2 schreef Kurt Sys:
>>
>> Reading the thread: generate al possible teams 
>> ,
>>  
>> I realized I was facing a slightly similar problem. Although many valuable 
>> suggestions were made, I'm very interested in one made 
>>  by 
>> puzzler, 
>> i.e. using loco (unless another method/library is more useful, suggestions 
>> are welcome).
>>
>> Now, the problem description: 
>> 1/ I have a set of players which must be divided in teams of two. If only 
>> teams of two is not possible, teams of three are allowed as well.
>> 2/ Every player has a set of characteristics. Based on these 
>> characteristics, some teams are not allowed, some are, and some are 
>> prefered.
>>
>> There are quite a few characteristics, so I'll build up the first few:
>> 1/ The main characteristic is 'level', ranging from 0-7. Only teams of 
>> two with total level of 5 or more are allowed. 
>> For teams of three, there are separate rules: there must be at least one 
>> level 3. If the highest level is 3, than no two levels 1 or less are 
>> allowed. 
>>
>> 2/ There is a characteristic 'experience' as well. Taking into account 
>> the exprience, there are more exceptions:
>> A level 3 and a level 1 is allowed (in contrast to rule 1: total should 
>> be at least 5), if the experience of level 1 is high enough
>> A level 4 and a level 1 are not allowed together, if the experience of 
>> level 1 is not high enough
>> Two levels 2 are allowed, if both are experienced enough
>>
>> So far, it's still pretty easy to find a solution: rank according to 
>> level and experience, and take each time the top and bottom from the li

Calling empty on a map entry

[Alex Engelberg]

(def map-entry (first {1 2}))
(empty map-entry)
=> nil

Up until now my understanding was that map entries are completely 
interchangeable with vectors, in that you can conj and assoc just like 
vectors, and you can even call them like functions. I figured that calling 
empty on a map entry would return an empty vector. Does this seem like a 
reasonable functionality demand, or can someone shed some light on why this 
is the current behavior?

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
--- 
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/d/optout.

Re: solving an equation for all solutions with constraints: core.logic.fd

[Alex Engelberg]

It doesn't totally make sense to me that you would have integer variables
with real coefficients. If the coefficients are irrational and are not
scaled versions of each other, then the problem is impossible. Otherwise,
you can just scale them by a common factor and make them integers. For
instance, you could turn 3.x + 2.y = 8.4 into 28x + 20y = 76.

--Alex


On Tue, Jun 10, 2014 at 2:30 PM, cej38  wrote:

> I picked a toy problem that was really easy to solve, figuring that once I
> had the idea down, I would be able to easily change the equation to the one
> that I am interested in solving.  In moving to my real problem I hit the
> next snag I can't use real numbers within the equation.  I note that the
> equation hasn't changed, the values of x and y are still non-negative
> integers.
>
> (run* [q]
>   (fresh [x y]
> (fd/in x y (fd/interval 0 9))
> (fd/eq
>   (= (+ (* x 3.) (* y 2.)) 8.))
> (== q [x y])))
>
> In my real problem I expect that I could have something like
>
> (run* [q]
>   (fresh [x y]
> (fd/in x y (fd/interval 0 9))
> (fd/eq
>   (= (+ (* x 3.) (* y 2.)) 8.))
> (== q [x y])))
>
> Is there away to do this?
>
>  --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/hje351kbvJA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/d/optout.

Re: solving an equation for all solutions with constraints: core.logic.fd

[Alex Engelberg]

I couldn't help but overhear that you're working with Constraint 
Programming, so I thought I'd suggest that you try loco 
, which is a Clojure wrapper of a Java 
library specifically designed to work with these types of problems.

The loco solution to your problem would look like this:
(use 'loco.core 'loco.constraints)
(solutions [($in :x 0 100)
($in :y 0 100)
($= ($+ ($* :x 2)
($* :y 3))
8)])
=> ({:y 0, :x 4} {:y 2, :x 1})
While loco doesn't free you from all the limitations you previously had 
(like having to specify arbitrarily large domains), it might be a better 
choice than core.logic in this case because I think it's more elegant to 
write problems, and it's much faster. (I wrote the library so I'm a bit 
biased.)

On Tuesday, June 10, 2014 8:32:33 AM UTC-7, David Nolen wrote:
>
> That's that's the suggested way - just pick a large bound. 
>
> David 
>
> On Tue, Jun 10, 2014 at 11:28 AM, cej38 > 
> wrote: 
> > I found the solution to my first problem at 
> > https://github.com/clojure/core.logic/wiki/Features (with a few small 
> > changes by me): 
> > 
> > (run* [q] 
> >   (fresh [x y] 
> > (fd/in x y (fd/interval 0 9)) 
> > (fd/eq 
> >   (= (+ (* x 3) (* y 2)) 8)) 
> > (== q [x y]))) 
> > 
> > 
> > I suppose that I could set (fd/interval 0 9) to do a fair 
> > approximation of the non-negative integers, but out of curiosity, would 
> > there be a better way of doing this? 
> > 
> > 
> > 
> > On Tuesday, June 10, 2014 11:12:11 AM UTC-4, cej38 wrote: 
> >> 
> >> I am interested in solving a simple equation for all of its solutions 
> when 
> >> some constraints are applied.  This sounds like a problem for 
> core.logic.fd. 
> >> 
> >> Let's use a toy example: 
> >> 
> >> 8 = 3*x + 2*y,  where x and y must be non-negative integers. 
> >> 
> >> Here are the possible solutions:  [x,y]= {[2,1],[0,4]}. 
> >> 
> >> 
> >> I tried something like this: 
> >> 
> >> (run* [q] 
> >>   (fresh [x y] 
> >>  (== q [x y]) 
> >>(project [x y] 
> >>   (fd/+ (* x 2) (y 3) 8 
> >> 
> >> But I get a exception: 
> >> "java.lang.ClassCastException: clojure.core.logic.LVar cannot be cast 
> to 
> >> java.lang.Number" 
> >> 
> >> So I have two questions: 
> >> 1. How should I rewrite the above command to get the solutions? 
> >> 2. Are there any good blog posts/online presentations/etc. on 
> >> core.logic.fd? 
> >> 
> >> 
> >> 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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/d/optout.

Re: [ANN] clj-generators - generator magic inspired by Python

[Alex Engelberg]

Gary, I fully acknowledge that there are many ways to create lazy sequences 
that are much more elegant and efficient. However, as I mentioned, I'm very 
fascinated by generators in Python, and I mostly wanted to toy around with 
how to implement it in Clojure. Also, as I mentioned, for beginners who are 
not well-versed in Clojure laziness, it's easy to use generators in 
combination with the "loop" macro (or other more imperative macros) for a 
lazy but still functional-ish sequence. However, I'm probably not going to 
use this library for any of my own projects. :-)

Thanks for the comments.
--Alex

On Wednesday, June 4, 2014 8:50:21 AM UTC-7, tbc++ wrote:
>
> A little known fact is that the guts of the go macro are quite flexible. 
> We use this in the test framework:
>
>
> https://github.com/clojure/core.async/blob/master/src/test/clojure/clojure/core/async/ioc_macros_test.clj#L17
>
> I also spent some time once and created a yield like macro:
>
>
> https://github.com/halgari/async-bench/blob/master/src/async_bench/core.clj#L64
>
> WARNING: this uses unpublished APIs from core.async, use at your own risk. 
>
> Timothy
>
>
> On Wed, Jun 4, 2014 at 9:43 AM, Gary Johnson  > wrote:
>
>> What new features does this syntax provide over the existing infinite 
>> sequence generators?
>>
>> - lazy-seq
>> - iterate
>> - repeat
>> - repeatedly
>> - range
>>
>> I realize you provided a simple example for clarity, but perhaps you 
>> could illustrate something more complex that couldn't be done with the 
>> above functions easily. For example, the case you provided could be written 
>> as follows:
>>
>> (take 5 (iterate inc 1))
>>
>>   Thanks,
>> ~Gary
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

-- 
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/d/optout.

[ANN] clj-generators - generator magic inspired by Python

[Alex Engelberg]

https://github.com/aengelberg/clj-generators

My all-time favorite feature of Python is "generators." It allows you to 
write lazy sequences imperatively.

def infinite_range():
x = 1
while True:
yield x
x += 1
for i in infinite_range():
if (i > 5):
break
else:
print(i)
=> 1 2 3 4 5

This feature is so amazing and powerful, a common practice of mine is to 
ponder how to implement such magic in other languages. Python implements 
this feature using virtual stacks to suspend the computation in memory. 
Most languages don't have a similar way to "pause" a computation like that, 
short of manipulating entire threads, which gets messy quickly. However, 
when core.async came out for Clojure, I realized that the go-blocks can in 
fact "pause" in a lightweight way (because they "park" as they read/write), 
so it came to mind as a possible candidate for a Python generator 
implementation. The infinite_range example above would translate to the 
following Clojure code:

(defn infinite-range []
  (generator
(loop [x 1]
  (yield x)
  (recur (inc x)

(take 5 (infinite-range))
=> (1 2 3 4 5)

I realize this is a bit more imperative than most Clojure programmers would 
like. However, the addition of generators allows functional macros like 
"loop" to create lazy sequences (like in the example above), which it 
previously was unable to do.

Check out the github site  
for more details. It's relatively slow and inefficient but serves as a 
proof-of-concept. Enjoy!

-- 
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/d/optout.

Re: [ANN] lein-4clj

[Alex Engelberg]

Admittedly these two libraries are very similar; I actually hadn't heard
about lein-fore-prob before (because it wasn't listed on the leiningen
plugin list wiki <https://github.com/technomancy/leiningen/wiki/plugins>).

Because I started working on this without knowledge of the other library,
it naturally has a few differences; one of which is that it creates
separate files while lein-fore-prob puts all the problems into one file
(unless multiple projects are created). Also, lein-4clj supports
project-less template creation, allowing for a quicker workflow if a
4clojure user wants to quickly try out a solution using the REPL.

Anyhow, the two projects are similar and serve essentially the same
purpose, so feel free to use whichever you'd like.

--Alex

--Alex


On Wed, Mar 19, 2014 at 4:55 PM, Alan Malloy  wrote:

> Can you explain the difference between this and
> https://github.com/bfontaine/lein-fore-prob? I haven't really looked
> since back when https://github.com/broquaint/lein-foreclojure-plugin was
> new (in lein 1!), but it seems like there is a lein2 plugin already.
>
>
> On Wednesday, March 19, 2014 4:37:46 PM UTC-7, Alex Engelberg wrote:
>>
>> 4clojure <http://www.4clojure.com/> is a great site for practicing
>> various datatypes and concepts in Clojure. However, the code editor on the
>> website is somewhat limited, mostly because it doesn't have a REPL to test
>> out individual parts of your code. I'm not affiliated with 4clojure in any
>> way, but I've created a leiningen plugin for working on 4clojure problems
>> in the comfort of your own IDE.
>>
>> https://github.com/aengelberg/lein-4clj
>> See the readme for more information and examples.
>>
>> Enjoy!
>> --Alex
>>
>  --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/7kJYUuLk62A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/d/optout.

[ANN] lein-4clj

[Alex Engelberg]

4clojure  is a great site for practicing various 
datatypes and concepts in Clojure. However, the code editor on the website 
is somewhat limited, mostly because it doesn't have a REPL to test out 
individual parts of your code. I'm not affiliated with 4clojure in any way, 
but I've created a leiningen plugin for working on 4clojure problems in the 
comfort of your own IDE.

https://github.com/aengelberg/lein-4clj
See the readme for more information and examples.

Enjoy!
--Alex

-- 
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/d/optout.

Re: [ANN] loco 0.1.0

[Alex Engelberg]

Floating-point domains (or "real domains") are currently not supported.

I think that Choco has some support for real vars, using an external 
engine. I'm not sure how that fits into Clojure's package managing system; 
I'll look into it sometime in the future.

Thanks for your interest in Loco!
--Alex

On Friday, March 7, 2014 10:47:31 PM UTC-8, Olli Piepponen wrote:
>
> Hi,
>
> Looks very interesting.
>
> I was playing around with it yesterday at REPL, and I could not figure out 
> how to do constraints with floats. Are all domains limited to integers at 
> the moment, and if so do you have plans to add support for floating point 
> domains in the future?
>
> - Olli
>
> On Saturday, March 8, 2014 6:41:43 AM UTC+7, Alex Engelberg wrote:
>>
>> Loco is now on version 0.2.0. The only major change is that I renamed 
>> "$all-different?" to "$distinct" (now takes a list of args instead of a 
>> variable number of args), and renamed "$circuit?" to "$circuit". This is 
>> mostly because I wanted to provide more consistency throughout the function 
>> names by eliminating question marks. I realize that this is a small set of 
>> changes to push so early, but I figured it was best to get it out there as 
>> early as possible so people won't get too attached to the old functions.
>>
>> --Alex
>>
>> On Tuesday, March 4, 2014 1:46:51 PM UTC-8, Alex Engelberg wrote:
>>>
>>> Hi everyone.
>>>
>>> About 6 months ago, I created a Constraint Programming library called 
>>> CloCoP <https://github.com/aengelberg/clocop>. It was a Clojure wrapper 
>>> for a Java library, and it mostly maintained the "imperative" propagation 
>>> style. However, I was recently inspired to rework the library to have a 
>>> more declarative, functional taste.
>>>
>>> You can visit the github page <https://github.com/aengelberg/loco> for 
>>> more details, but here is some sample code.
>>> (use 'loco.core)
>>> (use 'loco.constraints)
>>> (defn solve-problem []
>>>   (solution
>>> [($in :x 1 5)   ; x is between 1 and 5
>>>  ($in :y 1 5)   ; y is between 1 and 5
>>>  ($= ($+ :x 4) :y)] ; x + 4 = y
>>>   ))
>>> (solve-problem)
>>> => {:x 1, :y 5}
>>>
>>> When you call a constraint function (that begins with a dollar sign), 
>>> Clojure data is returned instead of a mysterious Java object.. The Java 
>>> library underneath is now only accessed when the entire problem is passed 
>>> to the "solution" function.
>>>
>>> Loco is a good choice for speedily solving integer-domain problems. Let 
>>> me know what you think of the new problem model; I believe that it allows 
>>> for easier construction and manipulation of a model before solving it.
>>>
>>> --Alex
>>>
>>

-- 
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/d/optout.

Re: [ANN] loco 0.1.0

[Alex Engelberg]

Loco is now on version 0.2.0. The only major change is that I renamed 
"$all-different?" to "$distinct" (now takes a list of args instead of a 
variable number of args), and renamed "$circuit?" to "$circuit". This is 
mostly because I wanted to provide more consistency throughout the function 
names by eliminating question marks. I realize that this is a small set of 
changes to push so early, but I figured it was best to get it out there as 
early as possible so people won't get too attached to the old functions.

--Alex

On Tuesday, March 4, 2014 1:46:51 PM UTC-8, Alex Engelberg wrote:
>
> Hi everyone.
>
> About 6 months ago, I created a Constraint Programming library called 
> CloCoP <https://github.com/aengelberg/clocop>. It was a Clojure wrapper 
> for a Java library, and it mostly maintained the "imperative" propagation 
> style. However, I was recently inspired to rework the library to have a 
> more declarative, functional taste.
>
> You can visit the github page <https://github.com/aengelberg/loco> for 
> more details, but here is some sample code.
> (use 'loco.core)
> (use 'loco.constraints)
> (defn solve-problem []
>   (solution
> [($in :x 1 5)   ; x is between 1 and 5
>  ($in :y 1 5)   ; y is between 1 and 5
>  ($= ($+ :x 4) :y)] ; x + 4 = y
>   ))
> (solve-problem)
> => {:x 1, :y 5}
>
> When you call a constraint function (that begins with a dollar sign), 
> Clojure data is returned instead of a mysterious Java object.. The Java 
> library underneath is now only accessed when the entire problem is passed 
> to the "solution" function.
>
> Loco is a good choice for speedily solving integer-domain problems. Let me 
> know what you think of the new problem model; I believe that it allows for 
> easier construction and manipulation of a model before solving it.
>
> --Alex
>

-- 
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/d/optout.

Re: Solving allocation problems; code review and core.logic

[Alex Engelberg]

I released a library yesterday called Loco, 
which might be what you're looking for. (David mentioned JaCoP, which is 
very similar to the Java library that Loco runs on.) You might also want to 
check out this blog 
post,
 
which gives an example of an optimization problem written in Loco.

I'd be happy to give you some advice about Loco programming if I could 
better understand the data representing your problem that you need to 
express, and what you're trying to optimize.

--Alex

On Wednesday, March 5, 2014 6:52:34 AM UTC-8, Laurens Van Houtven wrote:
>
> Hi!
>
>
> I've been experimenting solving some real-world problems related to
> organizing a sizable (2000-3000 people) programming conference with a
> strong open source flavor.
>
> My next problem is a bit more daunting.
>
> This conference has a financial aid program. People who can not afford
> to come to the conference are given grants that have to come out of a
> budget. The budget is much smaller than the sum of all requested
> grants, so it turns into an underspecified optimization problem. In
> order to make that issue slightly less bad, there's a score function
> so that we can bias in favor of certain people, e.g. speakers.
>
> I'm convinced the optimal solution, even assuming it exists, is
> impossible to find. The data is incomplete; it is not necessarily true
> that because you assign less than what people have requested that they
> won't accept the grant.
>
> I wrote an implementation that plausibly matches the above:
>
> https://github.com/lvh/hood/blob/master/src/hood/core.clj
>
> I'm sure that that code has a lot of flaws. I haven't really played
> with it enough yet. Code review on that is very welcome. Any
> suggestions for a cleverer allocation algorithm would also be much
> appreciated.
>
> That said, I really sent this e-mail because I was wondering to what
> extent core.logic could be applied to this problem. The "running your
> program in reverse" concept is potentially interesting here; I'm
> hoping that we could get answers to questions like "what would an
> application have to look like to get X dollars under our budget?"
>
> I seriously don't even know where to start. What would the logic
> variables be? It seems that a lot of the example code uses a single
> logic variable and then "structures" it in the let body; but I have no
> idea what that one variable would even mean.
>
> Perhaps I should just tackle some simpler logic programs first :-)
>
> Thanks in advance for your thoughts and comments!
> lvh
>
>

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

[ANN] loco 0.1.0

[Alex Engelberg]

Hi everyone.

About 6 months ago, I created a Constraint Programming library called 
CloCoP. 
It was a Clojure wrapper for a Java library, and it mostly maintained the 
"imperative" propagation style. However, I was recently inspired to rework 
the library to have a more declarative, functional taste.

You can visit the github page  for more 
details, but here is some sample code.
(use 'loco.core)
(use 'loco.constraints)
(defn solve-problem []
  (solution
[($in :x 1 5)   ; x is between 1 and 5
 ($in :y 1 5)   ; y is between 1 and 5
 ($= ($+ :x 4) :y)] ; x + 4 = y
  ))
(solve-problem)
=> {:x 1, :y 5}

When you call a constraint function (that begins with a dollar sign), 
Clojure data is returned instead of a mysterious Java object.. The Java 
library underneath is now only accessed when the entire problem is passed 
to the "solution" function.

Loco is a good choice for speedily solving integer-domain problems. Let me 
know what you think of the new problem model; I believe that it allows for 
easier construction and manipulation of a model before solving it.

--Alex

-- 
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: [ANN] CloCoP - constraint programming for Clojure

[Alex Engelberg]

To Daniel's comment: that's a great idea (I'm sorta new to this whole 
releasing-a-library thing so I didn't think of that), and I'll definitely 
make a branch for that if I think of a big idea that I want to implement 
that involves breaking changes. But I figure that if someone other than me 
thinks of something like that, we'll probably discuss it a bit and figure 
something out (rather than just showing up with a pull request).

To Dmitry's comment: I've actually never tried Choco, I essentially chose 
JaCoP because it occured first in my "Java Constraint Programming" google 
search. Now I'm seeing that a lot of constraint programmers use Choco, and 
I'll try it out. I will point out that JaCoP walked away with some bronze 
and silver medals (with Gecode getting ALL the golds) at the FlatZinc 
challenge. (Choco didn't compete at all, though.)

On Friday, September 13, 2013 12:32:31 AM UTC-7, Dmitry Groshev wrote:
>
> Great stuff!
>
> I'm wondering what's the "realworld" difference between JaCoP and CHOCO. 
> Why did you choose the former?
>
> On Tuesday, September 10, 2013 5:39:46 AM UTC+4, Alex Engelberg wrote:
>>
>> http://github.com/aengelberg/clocop
>>
>> CloCoP is a Clojure wrapper of the Java library JaCoP. The acronyms stand 
>> for "Clojure/Java Constraint Programming". This invites comparison to the 
>> core.logic library, and you may wonder why we need both. There are a few 
>> ways in which, in my opinion, the JaCoP system is better than core.logic:
>>
>>- JaCoP is more "plug-in-able," with an extensive set of 
>>customizations to the way that the search operates. There are interfaces 
>>for different components of the search, and each has several 
>>implementations. 
>>- I found that with core.logic, I was somewhat limited by the set of 
>>available constraints. JaCoP has many different constraints that seem to 
>>more suit my needs for solving challenging problems. 
>>- As the core.logic people 
>> say,<https://github.com/clojure/core.logic/wiki/External-solvers>JaCoP is 
>> anywhere from 10X-100X faster than core.logic at solving Finite 
>>Domain problems.
>>
>> JaCoP has a lot of "global constraints" which are very powerful and 
>> essential for describing certain problems. As Radoslaw Szymanek (an 
>> author of JaCoP) says, "CP without global constraints is just [a] plain 
>> academic toy. Using problems with arithmetic constraints is doing CP bad 
>> publicity."
>>
>> If you'd like to see implementations of sample problems in CloCoP, check 
>> out the test 
>> cases<https://github.com/aengelberg/clocop/tree/master/test/clocop>
>>  (https://github.com/aengelberg/clocop/tree/master/test/clocop).
>>
>

-- 
-- 
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: [ANN] CloCoP - constraint programming for Clojure

[Alex Engelberg]

It's under the Eclipse Public License (as stated in project.clj), with pull 
requests welcome. I just added the license info to the Readme as well. 
Sorry about the confusion.

I've also created a 0.2.1 branch (without any changes yet) for people to 
pull-request new features into. (Though if you're just submitting 
examples/tests, the master branch is fine.)

Thanks,
--Alex

On Wednesday, September 11, 2013 1:47:44 PM UTC-7, sesm wrote:
>
> Great stuff!
> Unfortunately, README doesn't say anything about license and contributing, 
> so I've sent a pull request to check it :) If you accept contributing 
> tests/examples, I would send a lot more.
>
> вторник, 10 сентября 2013 г., 5:39:46 UTC+4 пользователь Alex Engelberg 
> написал:
>>
>> http://github.com/aengelberg/clocop
>>
>> CloCoP is a Clojure wrapper of the Java library JaCoP. The acronyms stand 
>> for "Clojure/Java Constraint Programming". This invites comparison to the 
>> core.logic library, and you may wonder why we need both. There are a few 
>> ways in which, in my opinion, the JaCoP system is better than core.logic:
>>
>>- JaCoP is more "plug-in-able," with an extensive set of 
>>customizations to the way that the search operates. There are interfaces 
>>for different components of the search, and each has several 
>>implementations. 
>>- I found that with core.logic, I was somewhat limited by the set of 
>>available constraints. JaCoP has many different constraints that seem to 
>>more suit my needs for solving challenging problems. 
>>- As the core.logic people 
>> say,<https://github.com/clojure/core.logic/wiki/External-solvers>JaCoP is 
>> anywhere from 10X-100X faster than core.logic at solving Finite 
>>Domain problems.
>>
>> JaCoP has a lot of "global constraints" which are very powerful and 
>> essential for describing certain problems. As Radoslaw Szymanek (an 
>> author of JaCoP) says, "CP without global constraints is just [a] plain 
>> academic toy. Using problems with arithmetic constraints is doing CP bad 
>> publicity."
>>
>> If you'd like to see implementations of sample problems in CloCoP, check 
>> out the test 
>> cases<https://github.com/aengelberg/clocop/tree/master/test/clocop>
>>  (https://github.com/aengelberg/clocop/tree/master/test/clocop).
>>
>

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

[ANN] CloCoP - constraint programming for Clojure

[Alex Engelberg]

http://github.com/aengelberg/clocop

CloCoP is a Clojure wrapper of the Java library JaCoP. The acronyms stand 
for "Clojure/Java Constraint Programming". This invites comparison to the 
core.logic library, and you may wonder why we need both. There are a few 
ways in which, in my opinion, the JaCoP system is better than core.logic:

   - JaCoP is more "plug-in-able," with an extensive set of customizations 
   to the way that the search operates. There are interfaces for different 
   components of the search, and each has several implementations. 
   - I found that with core.logic, I was somewhat limited by the set of 
   available constraints. JaCoP has many different constraints that seem to 
   more suit my needs for solving challenging problems. 
   - As the core.logic people 
say,JaCoP is 
anywhere from 10X-100X faster than core.logic at solving Finite 
   Domain problems.

JaCoP has a lot of "global constraints" which are very powerful and 
essential for describing certain problems. As Radoslaw Szymanek (an author 
of JaCoP) says, "CP without global constraints is just [a] plain academic 
toy. Using problems with arithmetic constraints is doing CP bad publicity."

If you'd like to see implementations of sample problems in CloCoP, check 
out the test cases
 (https://github.com/aengelberg/clocop/tree/master/test/clocop).

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