automat reverse path

[Kurt Sys]

I'd like to use automat as a core engine  for web applications. It should 
be able to hold state, as a state machine does :). However, I can only see 
'forward' paths in automat (which is probably what a state machine is 
about). Taking 'the short example' on the webpage:

> (def pages [:cart :checkout :cart]) 
#'pages 
> (def page-pattern (vec (interpose (a/* a/any) pages))) 
#'page-pattern

returns a state machine for a web shop (omitting the reducers for now, 
since they don't matter). So, one can advance: :cart to :checkout, going 
'forward' after a :cart-trigger again, saving some data and sending an 
offer on the way. However, from the checkout, one should be able to 'go 
back' to the cart, so to have a 'cyclic' path:


:checkout/:save
  ---> 
 / :init:cart/:save /  \
:cart/:offer,:save
--> 0 ---> 12 
--> 3
\  /
  <---  
:go-back/:revert
  

I can imagine something like:


 :cart / 
:offer,:save  

---> 3 
 / :init:cart/:save:checkout/:save/ 
--> 0 ---> 1 --> 2 
  \

---> 4
:go-back / 
:revert

might be part of the solution: after step 4, advancing through a new finite 
state machine to step 1 gives a similar model. However, I wouldn't like to 
loose the data stored in step 4. So initializing the new finite state 
machine is extremely important. 

So... is this the right way of modelling this kind of 'reverse paths' (of 
which I may have quite a few in my machines, so it may be not very elegant 
to model it this way). How would I model this in automat?  (Or should I 
stick to what I do now, which is using core.async and a separate state map.)

Thx, qsys 

-- 
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: gen-class: override only 1 method of an arity-overloaded method of a (Java) superclass

[Kurt Sys]

Yeah... I actually wanted to avoid that - I don't really want to 
(publically) 'expose' them. It means I have to expose all arity-overloaded 
methods I want to use, and in some libraries, there are quite a lot of 
these. It just feels a bit weird to publically expose (protected) methods 
of superclasses - well, we're using classes here, so I do think in 
inheritance-based oop for this example.

Anyway, exposing is probably how to do it...

thanks, qsys

Op maandag 28 december 2015 04:22:36 UTC+1 schreef James Elliott:
>
> I don’t have a ton of experience with gen-class, but I think you need to 
> tell it to expose the superclass methods you want to call using 
> :exposes-methods, as described in 
> http://stackoverflow.com/questions/9060127/how-to-invoke-superclass-method-in-a-clojure-gen-class-method
>
> In case it is of any use, here is an example of where I successfully 
> subclassed a Java class from an external library and called some superclass 
> methods: 
> https://github.com/brunchboy/afterglow-max/blob/master/src/afterglow/max/Var.clj
>
> On Wednesday, December 23, 2015 at 3:23:41 AM UTC-6, Kurt Sys wrote:
>>
>> When using gen-class and arity-overloaded methods of a superclass seems 
>> not very obvious, or I am missing something...
>>
>> There's a (java) superclass 'some.Superclass' (which is from a library, 
>> so I can't change this one):
>>
>> public abstract class Superclass {
>>public void method() {
>>}
>>
>>public void method(Object something) {
>>   this.method();
>>   // other logic
>>}
>> }
>>
>>
>> I want to extend that base (abstract) class in clojure, using gen-class 
>> (since the class needs to accessible as a normal Java class). So the first 
>> thing I did was:
>>
>> (ns my.namespace
>>   (:gen-class
>>:name "my.namespace.ArityTest"
>>:extends some.Superclass
>>:prefix "some-")
>>  )
>>
>> (defn some-method
>>   [this]
>>   (println "1-arity"))
>>
>> However, this doesn't work: 'method' is arity-overloaded, when calling 
>> new ArityTest().method(new Object())
>>
>> I get a ArityException, wrong number of arguments (2). I suppose this is 
>> because I override 'method', so I have to override all arities? I'd like to 
>> have the 1-arity version to call it's superclass method, and I seem to fail 
>> at that. The last attempt is this: get the method of the superclass and 
>> call that method on 'this':
>>
>> (ns be.admb.kbf.vertx.shell.test
>> (:gen-class
>>   :name "my.namespace.ArityTest"
>>   :extends some.Superclass
>>   :prefix "some-")
>> )
>>
>>
>> (defn some-method
>>   ([this]
>> (println "1-arity"))
>>   ([this o]
>> (.invoke (-> this
>>  (.getClass)
>>  (.getSuperclass)
>>  (.getMethod "method"
>>  (into-array Class [java.lang.Object])))
>>  this (into-array Object [o]))
>> ))
>>
>> This fails: it calls the overriden method, not the superclass' method... 
>> (and the method keeps on calling itself).
>>
>> The question: how do I override only 1 method of an arity-overloaded 
>> method of a superclass in Clojure (using gen-class to generate a Java 
>> class)?
>>
>

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

gen-class and overriding only 1 (arity-)overloaded method of superclass

[Kurt Sys]

When using gen-class and arity-overloaded methods of a superclass seems not 
very obvious, or I am missing something :p.

There's a (java) superclass 'some.Superclass' (which is from a library, so 
I can't change this one):

public abstract class Superclass {
   public void method() {
   }

   public void method(Object something) {
  this.method();
  // other logic
   }
}


I want to extend that base (abstract) class in clojure, using gen-class 
(since the class needs to accessible as a normal Java class). So the first 
thing I did was:

(ns my.namespace
  (:gen-class
   :name "my.namespace.ArityTest"
   :extends some.Superclass
   :prefix "some-")
 )

(defn some-method
  [this]
  (println "1-arity"))


However, this doesn't work: since 'method' is arity-overloaded, when 
calling 
new ArityTest().method(new Object())

I get a ArityException, wrong number of arguments (2).

I suppose this is because I override 'method', so I have to override all 
arities. I'd like to have the 1-arity version to call it's superclass 
method, and I seem to fail at that one. The last attempt is this: get the 
method of the superclass and call that method on 'this':
(ns be.admb.kbf.vertx.shell.test
(:gen-class
  :name "my.namexpace.ArityTest
  :extends some.Superclass
  :prefix "some-")
)


(defn some-method
  ([this]
(println "1-arity"))
  ([this o]
(.invoke (-> this
 (.getClass)
 (.getSuperclass)
 (.getMethod "method"
 (into-array Class [java.lang.Object])))
 this (into-array Object [o]))
))


This fails: it calls the overriden method, not the superclass' method...

So well, how do I override only 1 method of an arity-overloaded method of a 
superclass in Clojure?

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

gen-class: override only 1 method of an arity-overloaded method of a (Java) superclass

[Kurt Sys]

When using gen-class and arity-overloaded methods of a superclass seems not 
very obvious, or I am missing something...

There's a (java) superclass 'some.Superclass' (which is from a library, so 
I can't change this one):

public abstract class Superclass {
   public void method() {
   }

   public void method(Object something) {
  this.method();
  // other logic
   }
}


I want to extend that base (abstract) class in clojure, using gen-class 
(since the class needs to accessible as a normal Java class). So the first 
thing I did was:

(ns my.namespace
  (:gen-class
   :name "my.namespace.ArityTest"
   :extends some.Superclass
   :prefix "some-")
 )

(defn some-method
  [this]
  (println "1-arity"))

However, this doesn't work: 'method' is arity-overloaded, when calling 
new ArityTest().method(new Object())

I get a ArityException, wrong number of arguments (2). I suppose this is 
because I override 'method', so I have to override all arities? I'd like to 
have the 1-arity version to call it's superclass method, and I seem to fail 
at that. The last attempt is this: get the method of the superclass and 
call that method on 'this':

(ns be.admb.kbf.vertx.shell.test
(:gen-class
  :name "my.namespace.ArityTest"
  :extends some.Superclass
  :prefix "some-")
)


(defn some-method
  ([this]
(println "1-arity"))
  ([this o]
(.invoke (-> this
 (.getClass)
 (.getSuperclass)
 (.getMethod "method"
 (into-array Class [java.lang.Object])))
 this (into-array Object [o]))
))

This fails: it calls the overriden method, not the superclass' method... 
(and the method keeps on calling itself).

The question: how do I override only 1 method of an arity-overloaded method 
of a superclass in Clojure (using gen-class to generate a Java class)?

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

[Kurt Sys]

Allright, makes sense... I must have mist the 'integer only' for all 
expressions (including $nth). Using 'map' seems to be doing what I expect 
(at first sight).

Thx!


Op woensdag 7 oktober 2015 05:50:37 UTC+2 schreef 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 
>>> <https://groups.google.com/forum/#!searchin/clojure/generate$20all$20possible$20teams/clojure/DeCBCD_dwRo/OyjJPgHXCAAJ>,
>>>  
>>> I realized I was facing a slightly similar problem. Although many valuable 
>>> suggestions were made, I'm very interested in one made 
>>> <https://groups.google.com/d/msg/clojure/DeCBCD_dwRo/nw4aW4zwCAAJ> 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

Re: finding optimal pairs/triplets

[Kurt Sys]

Yes! That's what I was looking for :). I really like the idea of 
'team-centric' and 'player-centric', and combining them! It might take me 
some time to figure it all out in detail, but with this idea and your 
example, I'll pretty confident I'll get there :). 
I could go for heuristics as well, but in that case I need to be able to 
rate team assignments, which is not that easy. For now, I just want to have 
all possible solutions and some information about violations etc, and let 
the user choose one to continue with. A weighted score (based on user 
weights) might be used for optimization, but in in my experience, users are 
not always that good using 'weights' which result in one optimized 
solution. Leaving a choice often feels better, meaning: the user feels of 
having full control. 
Anyway... using a kind of weighted score for each team might be another 
'feature' I might add, if I get the basic stuff to work :).

Thx a lot! 


Op woensdag 7 oktober 2015 06:48:06 UTC+2 schreef puzzler:
>
> Here is my Loco-based solution to the team-splitting problem:
> https://gist.github.com/Engelberg/d8007588ce5a83fd0303
>
> There is a whole art to building constraint programming models.  I know 
> the basics, but I'm not an expert, and your model sounds fairly 
> complicated.  So I'm not sure I can answer all your questions, but I can 
> point you in the right direction.  There is a Coursera course devoted to 
> this which I've been meaning to take:
> https://www.coursera.org/course/modelingoptimization
> You might find that interesting as well.  It uses minizinc, which has a 
> lot of similarities to loco (which wraps choco).  There exists a clojure 
> wrapper for minizinc, but I have not used it.
>
> Your approach seems like a good possibility.  I think, as you point out, 
> constrain spots 1 and 2 to being non-negative (since there must be players) 
> and then just adding more negative numbers to the range for spot 3 (as many 
> as there are teams) does the trick and then you can apply the $distinct 
> global constraint to all the spot variables.  I would probably go one step 
> further and say that team t can only have a player number or the specific 
> negative number -t in spot 3.  (So it doesn't waste time trying various 
> permutations of negative numbers in spot 3).
>
> Another possible approach is that each player is assigned a team number.  
> So variable t_i is the number of the team that player i is assigned to.  
> When doing something like this, you usually want to apply a 
> "symmetry-breaking strategy" by ensuring that the team numbers are assigned 
> in ascending order.  To do that, you add constraints along the line:
> t_i <= max(t_0, ..., t_i-1) + 1
>
> You could then use the frequencies global constraint to make sure that 
> each team has only 2 or 3 players.
>
> In fact, it is possible to simultaneously use both representations, by 
> connecting them to one another:
> for each player i, i should be in one of t_i's 3 spots.
>
> and then you are free to express each idea using either the player-centric 
> or team-centric view of things.
>
> Some of what you provide are logical constraints which can be enforced 
> using the appropriately modeled constraint.
>
> Then, you have a whole bunch of preferences you want to maximize and 
> violations you want to minimize.  The general approach for doing that is to 
> "reify" each of these things to a variable where 1 is the bad scenario 
> (violation of rule, or lack of fulfilling a preference) and 0 is the good 
> scenario.  The create a variable that sums these reified variables, and 
> minimize on that.
>
> I think for the scope of problem you're talking about (< 100 players), 
> loco could perform well for you.  But if not, as I mentioned in the other 
> thread, there are a lot of simple heuristics that are fairly easy to 
> implement in Clojure.  Once you have a way to rate your team assignments, 
> you just start with a random configuration and explore various swaps (this 
> may be a small enough number of players to explore all possible swaps from 
> a given state and go directly to the best rated result, otherwise use 
> random sampling).   Multiple restarts, tabu search, simulated annealing are 
> all easy to implement and can yield great results.  (Seems like building a 
> toolkit of these heuristics would be a fun library to put together for 
> Clojure!)
>
>
>

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

Re: finding optimal pairs/triplets

[Kurt Sys]

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 
> <https://groups.google.com/forum/#!searchin/clojure/generate$20all$20possible$20teams/clojure/DeCBCD_dwRo/OyjJPgHXCAAJ>,
>  
> I realized I was facing a slightly similar problem. Although many valuable 
> suggestions were made, I'm very interested in one made 
> <https://groups.google.com/d/msg/clojure/DeCBCD_dwRo/nw4aW4zwCAAJ> 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 list. That 
> should be pretty close to the most optimal solution. But there are more 
> characteristics for each player:
>
> 3/ There are preferences to put some players together, scored from 1 
> (avoid teaming them) to 7 (high preference to team them). Based on these 
> preferences, 'team preferences' might be calculated. If no 'preference' is 
> given, a value of 4 is assumed. In this example, I scored them per player, 
> but it might be done per team as well.
>
> 4/ Some players might have a 'handicap', so they need another levels to 
> team with. If possible, the handicaps should be used, but they may be 
> omitted if there is no other solution. In an extended version, a preference 
> level for a handicap for a certain player may be set as wel

finding optimal pairs/triplets

[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 list. That 
should be pretty close to the most optimal solution. But there are more 
characteristics for each player:

3/ There are preferences to put some players together, scored from 1 (avoid 
teaming them) to 7 (high preference to team them). Based on these 
preferences, 'team preferences' might be calculated. If no 'preference' is 
given, a value of 4 is assumed. In this example, I scored them per player, 
but it might be done per team as well.

4/ Some players might have a 'handicap', so they need another levels to 
team with. If possible, the handicaps should be used, but they may be 
omitted if there is no other solution. In an extended version, a preference 
level for a handicap for a certain player may be set as well.

There are quite a few of handicaps (like 4) and rules (like 1 and 2, which 
are just a small subset of all handicaps and rules.

The number of players will not be very high, up to max 100, so max 50 
teams, which might be important, since I don't think heuristics will have a 
high benefit in this case (but I might be wrong).

An example: 

The players:
P1 {:level 0 :experience 0}
P2 {:level 2 :experience 17}
P3 {:level 3 :experience 23 :handicap :cl }
P4 {:level 3 :experience 27 :preference {P2 2, P3 6}}
P5 {:level 6 :experience 50}
P6 {:level 5 :experience 55 :preference {P2 1}}

The handicap description: {:cl :needs-level 5}

The solution?
(solve [P1 P2 P3 P4 P5 P6])
results in a set with possible solutions (possibly with some timeout or 
after the first x solutions are found):
#{ 
  { [ [P6 P1] [P5 P2] [P4 P3] ]
:unmatched-handicaps 1
:team-preferences [4 4] [4 4] [4 6] }
  { [ [P5 P1] [P6 P2] [P4 P3] ]
:unmatched-handicaps 1
:team-preferences [4 4] [1 4] [4 6] }
  { [ [P5 P3] [P6 P1] [P4 P2] ]
:unmatched-handicaps 0
:team-preferences [4 4] [4 4] [2 4] }
  ... }

Since puzzler said 'I can provide an example of that if you are interested' 
(for generating 'balanced teams' with restrictions with loco)... I'm 
interested :).

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: top-level lets or private globals

[Kurt Sys]

Allright, so I'll probably stick to top-level lets... Thx!

Op woensdag 26 augustus 2015 18:44:18 UTC+2 schreef Herwig Hochleitner:

 I can't really speak to what's more idiomatic, but there is a slight 
 difference between a top-level let and ^:const ^:private.
 ^:const makes the compiler directly inline the form, thus it works only on 
 pr-dup - able values. This has gotten me by surprise some times.
 This also duplicates values, that would otherwise be referenced.

 OTOH, a let compiles into a static field + regular access, also it's more 
 private in the sense that you can't even get it by the (rather obscure) 
 @#'private-var form
 ​
 Personally, I think there is nothing wrong with top-level lets and I like 
 to use them, just to keep compiler writers honest. There had been a 
 clojurescript bug related to this once.
 Also they are more explicit about scope than the reference tree implicit 
 in namespace vars.


-- 
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: top-level lets or private globals

[Kurt Sys]

I do understand that point of view and largely agree. However, some (pretty 
small) functions or constants are private to some namespace, or rather, to 
some scope inside a namespace. I consider the public functions as the 'API 
of the namespace'. Internals shouldn't be exposed, so I can change 
internals without having to worry about public access changes. Having 
everything public would be a real pain and since internals change quite 
often, like in about 80% of the cases, I'd be torturing myself :p.

So yes, I agree to avoid global privates, but not 'private' in a general 
sense. Everything binding in a let-special form is like private to that 
let-block. But 

 ... is this really private or is it a bit of instance state that really 
 shouldn't be a global def anyway. 

seems to me answering my question: do not use global private defs, but use 
(top-level?) let-blocks.


Thx, qsys

Op donderdag 27 augustus 2015 01:15:14 UTC+2 schreef red...@gmail.com:

 I have found the access control stuff in Java to be an incredible pain. 
 When attempting to compose a larger system from the parts. Generally 
 everything is compulsively private, so if an api doesn't exactly expose 
 what you want, you either have to write what you want completely from 
 scratch, or use reflection to get a the bits you want to compose in to 
 what you want. 

 Avoid private as much as you can, and if you think you can't, ask 
 yourself, is this really private or is it a bit of instance state that 
 really shouldn't be a global def anyway. 

 When I make the case for making everything public generally the argument 
 I get back is about api evolution and how do users know what the stable 
 parts of the api are? I think this concern is a result of using 
 languages and tooling that don't do a good job of distinguishing source 
 code used to build an artifact and an artifact. Clojure tooling is 
 mostly built on top of maven, which does an excellent job of 
 distinguishing between the two. If you build your code using a jar out 
 of maven with a fixed version of 1.0.1, unless you change your 
 dependency you will always get the same code, so who cares what the 
 author decided is the stable public api and what is the private api. 
 Anything that you can make use of you can, and it will be the same until 
 you change it. 

 The answer to that is generally something about semantic versioning, 
 which due to every high profile project that uses it having at some 
 point a heated argument about what does and does not constitute a patch 
 release, who knows what you getting anyway. 

 -- 
 And what is good, Phaedrus, 
 And what is not good— 
 Need we ask anyone to tell us these things? 


-- 
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: top-level lets or private globals

[Kurt Sys]

Well, honestly, I tend to use pretty big lets in my namespaces. I know I 
can use (private) namespace-scoped variables (or rather, contstants :) ) , 
but somehow, I don't really like them. So what I mostly have now:

(ns my.namespece
  (require [other.namespace : as o]
  [cool.namespace :refer [coolyo]]

(defn- silly-function []
  ...)

(defn- another-variable-independent-function []
  ...)

(let [a bunch of constants/variables used in (almost?) all public functions
]
  (defn some-api-function []
...)
  (defn call-me-please []
...) )

I've put some (private, mostly pretty small) 'helper'-functions outside the 
let-block. I like this kind of construct in some way. It makes a clear 
distinction between:

   1. functions that don't use the 'namespace constants'
   2. helper functions (very often, most of these can be put in a kind of 
   seperate 'utility' namespace, but not always)
   
However, there are some againsts this as well (as slightly discussed in 
other threads), by example:
https://groups.google.com/d/msg/clojure/r_ym-h53f1E/2brnaduLYr4J
https://groups.google.com/d/msg/clojure/r_ym-h53f1E/O-Tvhgqt8lcJ

Instead of putting most stuff inside a big 'let', one could also argue to 
define a bunch of 'globals':
(def ^const ^{:private true} my-constant some-value)
I'm not sure whether it makes a difference to add the ^{private 
true}-metadata, but ^const surely does improve performance, which might be 
important. Anyway, defining a bunch of global constants seems to work quite 
similar to a rather big let. 

I'm just wondering what's idiomatic or considered best practice in Clojure 
(and why) because euh... well, just because I want to know :).



Op dinsdag 25 augustus 2015 23:27:19 UTC+2 schreef Alan Thompson:

 *** premature send ***

 Ya know, I've never seen that before but I like it!

 I have previously noticed (by accident) that you can have naked 
 expressions in a file/namespace (i.e. not inside of a def/defn).  For 
 example, I use a statement like this:

 (ns ...
   (:require [tupelo.core :refer [spyx]] ...
 (spyx *clojure-version*)


 at the top of my main testing namespace tst.tupelo.core to get:

 *clojure-version* = {:major 1, :minor 8, :incremental 0, :qualifier 
 alpha4}


 printed at the top of every test run.  Another favorite is:

 (ns ...

   (:require [schema.core :as s] ...

 ; Prismatic Schema type definitions
 (s/set-fn-validation! true) 


 to control Prismatic Schema in each namespace.

 I have also used other naked expressions (in both test and regular 
 files/namespaces) as a kind of free-form scratchpad when experimenting with 
 new code (since I can type so much faster in the editor than the repl).

 Thanks for the suggestion,
 Alan
  

 On Tue, Aug 25, 2015 at 2:19 PM, Alan Thompson cloo...@gmail.com 
 javascript: wrote:

 Ya know, I've never seen that before but I like it!

 I have noticed that you can have naked expressions in a file (i.e. not 
 inside of a def/defn).  For example, I use a statement like this:

 (require '[tupelo.core :refer [spyx]])
 (spyx *clojure-version*)

 at the top of my main testing namespace tst.tupelo.core to get:

 *clojure-version* = {:major 1, :minor 8, :incremental 0, :qualifier 
 alpha4}

 printed


 Alan

 On Tue, Aug 25, 2015 at 12:06 AM, Kurt Sys kurt...@gmail.com 
 javascript: wrote:

 I'm refering to a few posts in an old thread:
 https://groups.google.com/d/msg/clojure/r_ym-h53f1E/RzUdb5oYeX4J

 What really puzzles me is that it doesn't seem to be generally 
 regarded as idiomatic Clojure style to just use top-level (let)s for 
 your private globals.

  
 So, here's the question: what's considered best practice in Clojure 
 (what is idiomatic in Clojure): using private (namespace-scoped) globals 
 variables or one big let over all (or at least, most) defns in a namespace? 
 And why :)?

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

Re: top-level lets or private globals

[Kurt Sys]

**EDIT:
I've put some (private, mostly pretty small) 'helper'-functions outside the 
let-block. I like this kind of construct in some way. It makes a clear 
distinction between:

   1. functions that don't use the 'namespace constants', mostly helper 
   functions (very often, most of these can be put in a kind of seperate 
   'utility' namespace, but not always)
   2. functions that do use the 'namespace constants', mostly the public 
   namespace functions (to be called from another namespace)
   


Op dinsdag 25 augustus 2015 14:14:52 UTC+2 schreef Kurt Sys:

 I'm refering to a few posts in an old thread:
 https://groups.google.com/d/msg/clojure/r_ym-h53f1E/RzUdb5oYeX4J

 What really puzzles me is that it doesn't seem to be generally 
 regarded as idiomatic Clojure style to just use top-level (let)s for 
 your private globals.

  
 So, here's the question: what's considered best practice in Clojure (what 
 is idiomatic in Clojure): using private (namespace-scoped) globals 
 variables or one big let over all (or at least, most) defns in a namespace? 
 And why :)?


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

top-level lets or private globals

[Kurt Sys]

I'm refering to a few posts in an old thread:
https://groups.google.com/d/msg/clojure/r_ym-h53f1E/RzUdb5oYeX4J

What really puzzles me is that it doesn't seem to be generally 
 regarded as idiomatic Clojure style to just use top-level (let)s for 
 your private globals.

 
So, here's the question: what's considered best practice in Clojure (what 
is idiomatic in Clojure): using private (namespace-scoped) globals 
variables or one big let over all (or at least, most) defns in a namespace? 
And why :)?

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