Re: Code Review

[Ralf Schmitt]

Sven Richter sver...@googlemail.com writes:

 HI,

 I just posted a question to stackoverflows code review 
 page:http://codereview.stackexchange.com/questions/90809/remove-lines-from-a-2d-vec-in-clojure

 As there is not much traffic regarding clojure I also double post to this 
 list in the hope to get some good answers. You might respond here or there, 
 whatever you like best.

 I have some code here that I am very unhappy with. The task I am trying to 
 accomplish is this.

 Given a 2d vec like this:

 [[0 2 0] [1 3 5] [3 3 0]]
 which can contain positive ints including zero I want to remove all _lines_ 
 that are greater zero.  
 Whereas the definition of _line_ is the following:  
 A _line_ is represented by the position n in every vec inside the 2d vec. 
 So my example above has three lines: 

 [0 1 3], [2 3 3] and [0 5 0].

 The line that I want to remove from it according to my algortihm is **[2 3 
 3]** because every element is greater than zero.

 So my 2d vec would now look like this:

 [[0 0] [1 5] [3 0]]

 And finally I want to pad the vecs to their original size filling them with 
 zero for every removed line, so that it looks finally like this:

 [[0 0 0] [0 1 5] [0 3 0]]


You want to transpose the matrix before working with it.
The following code should do what you want:

(def v [[0 2 0] [1 3 5] [3 3 0]])

(defn transpose
  [v]
  (apply map vector v))

(defn all-positive?
  [line]
  (every? pos? line))

(defn remove-non-zero-lines
  [lines]
  (let [removed (remove all-positive? lines)
zero-line (vec (repeat (count (first lines)) 0))]
(concat
 (repeat (- (count lines) (count removed)) zero-line)
 removed)))

(defn doit
  [v]
  (- v transpose remove-non-zero-lines transpose))

-- 
Cheers
Ralf

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

Code Review

[Sven Richter]

HI,

I just posted a question to stackoverflows code review 
page:http://codereview.stackexchange.com/questions/90809/remove-lines-from-a-2d-vec-in-clojure

As there is not much traffic regarding clojure I also double post to this 
list in the hope to get some good answers. You might respond here or there, 
whatever you like best.

I have some code here that I am very unhappy with. The task I am trying to 
accomplish is this.

Given a 2d vec like this:

[[0 2 0] [1 3 5] [3 3 0]]
which can contain positive ints including zero I want to remove all _lines_ 
that are greater zero.  
Whereas the definition of _line_ is the following:  
A _line_ is represented by the position n in every vec inside the 2d vec. 
So my example above has three lines: 

[0 1 3], [2 3 3] and [0 5 0].

The line that I want to remove from it according to my algortihm is **[2 3 
3]** because every element is greater than zero.

So my 2d vec would now look like this:

[[0 0] [1 5] [3 0]]

And finally I want to pad the vecs to their original size filling them with 
zero for every removed line, so that it looks finally like this:

[[0 0 0] [0 1 5] [0 3 0]]

This is what I came up with:

(defn in?
  true if seq contains elm
  [seq elm]
  (some #(= elm %) seq))

(defn not-in?
  true if seq does not contain elm
  [seq elm]
  (not (in? seq elm)))

(defn all-greater-zero-at
  Given a 2-d vec [[0 1] [0 2]] return true if all elements at 'at' are
  greater than zero
  [v at]
  (not-in? (map #(if ( (nth % at) 0) true false) v) false))

(defn to-be-removed
  Returns a seq of positions to be removed (0 3 4)
  [v width]
  (reduce (fn [a b] (if (all-greater-zero-at v b) (conj a b) a)) [] 
(range width)))

(defn remove-at
  Removes an element from a 1d vec
  [v at]
  (into [] (concat (subvec v 0 at) (subvec v (+ at 1) (count v)

(defn insert-at
  inserts an element into a 1d vec
  [v elm at]
  (into [] (concat (subvec v 0 at) elm (subvec v at (count v)

(defn remove-and-replace-all-at
  [v at]
  (map #(insert-at (remove-at % at) [0] at) v))

(defn replace-full-by-zero [v width]
  (reduce (fn [a b] (remove-and-replace-all-at a b)) v (to-be-removed v 
width)))

(defn remove-zeros [v at]
  (reduce (fn [a b] (conj a (remove-at b at))) [] v))

(defn fill-with-zeros
  Takes a 2d vec and pads ith with zeros up to width
  [v width]
  (map #(into [] (concat (take (- width (count (first v))) (repeat 0)) 
%)) v))

(defn clean-grid
  removes all full lines
  [fbz tbr]
  (loop [acc fbz tbr tbr i 0]
(if (empty? tbr)
  acc
  (recur (remove-zeros acc (- (first tbr) i)) (rest tbr) (inc i)

(defn remove-full-lines [v width]
  (let [fbz (replace-full-by-zero v width)
tbr (to-be-removed v width)
cleaned-grid (clean-grid fbz tbr)]
(into [] (fill-with-zeros cleaned-grid width

This seems like a lot of code for such a simple algorithm and I assume 
there are a lot of better ways to do that, but just did not come up with a 
better one, so, please, go ahead and fix it, if you want to :-)

Best Regards,
Sven

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

Managing database schema

[René Groß]

I can suggest https://github.com/teropa/lein-flyway, which wraps the 
functionality of flyway into leiningen commands.

-- 
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: a record that implements the iFn protocol can itself be called as a function?

[skuro]

Why not trying it right away in the REPL?

user= (defrecord Bar [state]) ; - not implementing IFn
 user.Bar
 user= ((-Bar foo)) 


 ClassCastException user.Bar cannot be cast to clojure.lang.IFn 
  user/eval15532 (form-init5689008917050406381.clj:1)
 user= (defrecord Foo [state] clojure.lang.IFn (invoke [this] (println my 
 state is state)))
 user.Foo
 user= ((-Foo foo))
 my state is foo
 nil

user= ((-Foo foo bar))
 ArityException Wrong number of args (2) passed to: 
 user/eval15486/-Foo--15498  clojure.lang.AFn.throwArity (AFn.java:429) 


Here you have it: implementing IFn is enough to use a record as a function. 
You can then implement just the arities you're interested into.

Cheers,
c.

Il giorno giovedì 14 maggio 2015 21:32:37 UTC+2, piast...@gmail.com ha 
scritto:

 The docs offer this example: 

 https://clojuredocs.org/clojure.core/defrecord

 user= (defrecord Someone [nick-name preffered-drink] Fun-Time (drinky-drinky 
 [_] (str nick-name (having  preffered-drink ): uuumm)))
 user.Someone

 user= (def dude (-Someone belun daiquiri))
 #'user/dude

 user= (drinky-drinky dude)
 belun(having daiquiri): uuumm

 But if a record implements clojure.lang.IFn it can be called directly? Do I 
 understand this correctly? When I run macroexpand-all on defrecord-ifn, as 
 defined here: 

 https://github.com/overtone/overtone/blob/e200075da27375727db1f5ce342e2e1c22ea1dbd/src/overtone/helpers/lib.clj

 I see that it extends clojure.lang.IFn as in: 

 clojure.lang.IFn 
 (invoke [this__1446__auto__] 
   ((fn [this  args] 
 (apply synth-player sdef params this [:tail instance-group] args)) 
 this__1446__auto__)) 
 (invoke [this__1447__auto__ arg0] 
   ((fn [this  args] 
 (apply synth-player sdef params this [:tail instance-group] args)) 
 this__1447__auto__ arg0)) 
 // etc, all 20 arities are defined

 So, that means I could call the record as a function? 




-- 
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: Code Review

[Ray Miller]

If I've understood the problem correctly, you can simplify the code by
implementing a transpose function:

(defn transpose [xs] (apply map vector xs))

Then define a wanted? function for filtering the lines you want to include:

(defn wanted? [xs] (some zero? xs))

...and a helper function to left-pad a vector with zeroes:

(defn lpad [n xs] (vec (concat (repeat (- n (count xs)) 0) xs)))

So your main function would look something like:

(defn process [xs] (let [n (count (first xs))] (vec (map (partial lpad
n) (transpose (filter wanted? (transpose xs)))

On 15 May 2015 at 09:01, Sven Richter sver...@googlemail.com wrote:
 HI,

 I just posted a question to stackoverflows code review
 page:http://codereview.stackexchange.com/questions/90809/remove-lines-from-a-2d-vec-in-clojure

 As there is not much traffic regarding clojure I also double post to this
 list in the hope to get some good answers. You might respond here or there,
 whatever you like best.

 I have some code here that I am very unhappy with. The task I am trying to
 accomplish is this.

 Given a 2d vec like this:

 [[0 2 0] [1 3 5] [3 3 0]]
 which can contain positive ints including zero I want to remove all _lines_
 that are greater zero.
 Whereas the definition of _line_ is the following:
 A _line_ is represented by the position n in every vec inside the 2d vec. So
 my example above has three lines:

 [0 1 3], [2 3 3] and [0 5 0].

 The line that I want to remove from it according to my algortihm is **[2 3
 3]** because every element is greater than zero.

 So my 2d vec would now look like this:

 [[0 0] [1 5] [3 0]]

 And finally I want to pad the vecs to their original size filling them with
 zero for every removed line, so that it looks finally like this:

 [[0 0 0] [0 1 5] [0 3 0]]

 This is what I came up with:

 (defn in?
   true if seq contains elm
   [seq elm]
   (some #(= elm %) seq))

 (defn not-in?
   true if seq does not contain elm
   [seq elm]
   (not (in? seq elm)))

 (defn all-greater-zero-at
   Given a 2-d vec [[0 1] [0 2]] return true if all elements at 'at' are
   greater than zero
   [v at]
   (not-in? (map #(if ( (nth % at) 0) true false) v) false))

 (defn to-be-removed
   Returns a seq of positions to be removed (0 3 4)
   [v width]
   (reduce (fn [a b] (if (all-greater-zero-at v b) (conj a b) a)) []
 (range width)))

 (defn remove-at
   Removes an element from a 1d vec
   [v at]
   (into [] (concat (subvec v 0 at) (subvec v (+ at 1) (count v)

 (defn insert-at
   inserts an element into a 1d vec
   [v elm at]
   (into [] (concat (subvec v 0 at) elm (subvec v at (count v)

 (defn remove-and-replace-all-at
   [v at]
   (map #(insert-at (remove-at % at) [0] at) v))

 (defn replace-full-by-zero [v width]
   (reduce (fn [a b] (remove-and-replace-all-at a b)) v (to-be-removed v
 width)))

 (defn remove-zeros [v at]
   (reduce (fn [a b] (conj a (remove-at b at))) [] v))

 (defn fill-with-zeros
   Takes a 2d vec and pads ith with zeros up to width
   [v width]
   (map #(into [] (concat (take (- width (count (first v))) (repeat 0))
 %)) v))

 (defn clean-grid
   removes all full lines
   [fbz tbr]
   (loop [acc fbz tbr tbr i 0]
 (if (empty? tbr)
   acc
   (recur (remove-zeros acc (- (first tbr) i)) (rest tbr) (inc i)

 (defn remove-full-lines [v width]
   (let [fbz (replace-full-by-zero v width)
 tbr (to-be-removed v width)
 cleaned-grid (clean-grid fbz tbr)]
 (into [] (fill-with-zeros cleaned-grid width

 This seems like a lot of code for such a simple algorithm and I assume
 there are a lot of better ways to do that, but just did not come up with a
 better one, so, please, go ahead and fix it, if you want to :-)

 Best Regards,
 Sven

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

Controlling growth rates of generators with test.check

[Mikera]

Hi all,

I am doing some generative testing with test.check and need a way to 
control the growth rate of data structures (the regular linear growth 
quickly makes the computations too large for meaningful testing usage). I 
came up with the following solution to do this:

(defn gen-resize 
  Creates a generator that pre-modifies the 'size' pramater with the 
function f. Use if you want to 
   have the size grow at a different rate from the normal linear scaling.
  ([f gen]
(let [gf (or (:gen gen) gen paramter must be a test.check generator)
  new-gf (fn [rnd size]
   (gf rnd (f size)))]
  (clojure.test.check.generators.Generator. new-gf

Normal O(n) growth:

(gen/sample gen/s-pos-int 30)
= (1 2 3 2 4 5 4 7 6 3 3 7 10 4 8 11 14 12 6 10 9 1 8 21 12 16 25 25 21 6)

Controlled O(sqrt(n)) growth:

(gen/sample (gen-resize sqrt gen/s-pos-int) 30)
= (1 2 2 2 2 4 3 3 3 3 4 3 5 1 2 3 2 4 4 2 2 3 6 6 2 5 5 4 6 3)

So it seems to work, but is this a sane / recommended approach? Am I 
relying too much on test.check internals?

  mikera

-- 
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: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Amith George]

Thanks for the detailed suggestions. Implementing them did bring the 
execution time down to around 250secs. Though that value is still much 
longer than 45secs. Could you please verify if I have implemented them 
correctly?

Code - 
https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/4ec02600e025d257a59d76fee0ad0eb01f4785ff/src/rdp/214_intermediate_arr.clj

project.clj contains the line 

:jvm-opts ^:replace [-Xms1024m -Xmx1g -server]

   0) Switch to Clojure 1.7.0-beta3 - it's faster and some things below 
are dependent on it for best performance. And use Java 1.8.

Done. 

   1) Parse the lines you're reading directly into longs (Clojure focuses 
on 64-bit primitives - longs and doubles)

(defn- read-line-nums
  ([] (read-line-nums (read-line) #(Long/parseLong %1)))
  ([input-line parse-fn]
   (if-let [line input-line]
 (- line
  (#(clojure.string/split %1 # ))
  (map parse-fn)

   2) Put the longs first into a data structure that preserves the 
primitive type. The two best options for that here are records (which can 
have primitive fields) and arrays. I would create a Canvas defrecord with 
^long width and height and a Paper defrecord with all ^long fields for 
example.

(defrecord Paper [^long color 
  ^long x1  ^long y1
  ^long x2 ^long y2])

(defrecord Canvas [^long width ^long height])

(defn- make-paper
  ([^long w ^long h] (make-paper [0 0 0 w h]))
  ([^longs [color x y w h]]
   (Paper. color x y (+ x w -1) (+ y h -1

I had to make the second arity accept a vector, as it seems impossible to 
create a function accepting more than 4 primitive arguments. Though I 
suppose I could grouped the args into a `record` of its own?

   3) Store the papers in a vector (using transient to create it)

The `read-input-file` function which creates and stores the papers, it 
finishes within 20ms. So I didn't bother using a transient. 

   4) I suspect visible-color and covered? could probably be tightened up 
into a reduce over papers or a single loop-recur over papers - can't say I 
totally get what's happening there.

The papers vector represents a sheets of papers that have been stacked on 
top of each other. ie, the last element in the vector is the canvas, and 
the first element is the topmost sheet. Each sheet is of different 
dimensions. Depending on the coordinates where they are placed, they may 
cover a part of the canvas. Different sheets may overlap in the areas they 
cover and thus we only want to consider the topmost sheet for that area. 

The `visible-color` function accepts a canvas coordinate and the stack 
papers and goes through the stack to find the first sheet that covers said 
coordinate. That papers color will be visible color for that coordinate.

   5) In visible-color-frequencies, you could use update instead of get 
+ transient assoc! on the acc map, but this is never going to be terribly 
fast. Another option here would be to create an array with the max color 
(you could track that while reading if it's not a well-known answer) and 
bash the array. That can retain int or long counters and will be *way* 
faster.

(defn- visible-color-frequencies-arr
  [{:keys [colors canvas papers]}]
  (let [colorCounts (long-array (count colors))] 
(reduce 
 (fn [_ ^longs coord]
   (if-let [color (visible-color coord papers)]
 (aset-long colorCounts color (+ 1 (aget colorCounts color)))
 _))
 -1
 (for [^long y (range (:height canvas))
   ^long x (range (:width canvas))]
   [x y]))
 (zipmap (range) colorCounts)))

It's a bit messy with me abusing reduce and totally ignoring the 
accumulator, but the version using arrays is atleast 10 seconds faster than 
the one using transient maps. That said, even the hashmap version took 
around 260-270secs. So the bulk of the time savings is caused by some other 
change. 

   6) You can use (set! *unchecked-math* :warn-on-boxed) to get faster 
math (no overflow checks) and also issue warnings (added in 1.7) if you 
happened to use boxed math by accident. 

I added these to both the old code (which didn't use type hints) and the 
new one. I ran the `-main` function of both from within the repl and using 
lein run. I didn't see any warnings in any of the executions. How am I 
supposed to use these?

(defn -main 
  ([] (-main 0 false))
  ([index use-arrays] 
   (time 
(binding [*unchecked-math* :warn-on-boxed
  *warn-on-reflection* true] 
  (if-not (Boolean/parseBoolean use-arrays) 
(solve (input-files (Integer/parseInt index)))
(solve-arr (input-files (Integer/parseInt index

   Use: ^:jvm-opts ^:replace [-server] 

In my case there isn't any noticable difference between explicitly using 
'-server' and not using it. Which brings me to my final 

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Jony Hudson]

@puzzler -server is the default mostly, but Leiningen overrides some of the 
important options that -server enables, as detailed by Alex.

@Lee the first 15 minutes of this talk by Tom Crayford has some useful info 
about performance and JVM options in it:

https://skillsmatter.com/skillscasts/6148-opening-the-grimoire-some-things-about-clojure-performance

For the record for my long-running workloads (which I suspect are _very_ 
similar to yours) I use:

:jvm-opts ^:replace [-server
 ;;-XX:+AggressiveOpts
 ;;-XX:+UseFastAccessorMethods
 ;;-XX:+UseCompressedOops
 -Xmx4g]


The commented out options are in there so I don't forget them (I learned 
some of them from Tom's talk), but I haven't found them to make any much 
difference for my jobs.


Jony


On Thursday, 14 May 2015 09:02:42 UTC+1, Amith George wrote:

 I wrote the following code to solve this challenge - 
 https://www.reddit.com/r/dailyprogrammer/comments/35s2ds/20150513_challenge_214_intermediate_pile_of_paper/
 .

 Code - 
 https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/56ce1dbb6a08e96150dc85934caecfeb68108a53/src/rdp/214_intermediate.clj

 I executed the -main function using `lein run 1`. 

 Output

 ;; lein run 1

 0 12605919
 1 3578145
 2 15356894
 3 19134293
 4 2394558
 5 15030409
 6 6424953
 7 14893444
 8 1592254
 9 1914025
 10 7075106
 Elapsed time: 501168.972435 msecs

 The code originally used an immutable hashmap, but I lost patience waiting 
 for the computation to end. With mutable hashmap, it still takes around 8 
 mins.

 I wrote a C# version of the above code - 
 https://gist.github.com/amithgeorge/766b8220f39d48221e58. It finishes 
 under 40secs. The C# exe was built under Release mode and executed directly 
 from the commandline. I expected the Clojure version to perform similarly.

 Any tips on what I am doing wrong?

 -
 Explanation of the code - Create a vector of all paper sheets, such that 
 the sheet placed last is the first element of the vector and the last 
 element is the canvas. To compute the frequency of each visible color - for 
 each point in the canvas find the first sheet in the vector that covers the 
 point. Store/increment its count in the hashmap. I understand there might 
 be better more efficient ways to solve this, but currently I am interested 
 in why the Clojure versions is so slow vis-a-vis the C# version.



-- 
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: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Lee Spector]

Thanks Jony -- very helpful!

 -Lee

 On May 15, 2015, at 7:52 AM, Jony Hudson jonyepsi...@gmail.com wrote:
 
 @puzzler -server is the default mostly, but Leiningen overrides some of the 
 important options that -server enables, as detailed by Alex.
 
 @Lee the first 15 minutes of this talk by Tom Crayford has some useful info 
 about performance and JVM options in it:
 
 https://skillsmatter.com/skillscasts/6148-opening-the-grimoire-some-things-about-clojure-performance
 
 For the record for my long-running workloads (which I suspect are _very_ 
 similar to yours) I use:
 
 :jvm-opts ^:replace [-server
  ;;-XX:+AggressiveOpts
  ;;-XX:+UseFastAccessorMethods
  ;;-XX:+UseCompressedOops
  -Xmx4g]
 
 The commented out options are in there so I don't forget them (I learned some 
 of them from Tom's talk), but I haven't found them to make any much 
 difference for my jobs.
 
 
 Jony

-- 
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: Protocols/multimethods vs core.match

[Surgo]

core.match compiles down to case, does it not? So the comparisons here are 
similar: http://insideclojure.org/2015/04/27/poly-perf/

-- Morgon

On Friday, May 15, 2015 at 2:57:23 PM UTC-4, tbc++ wrote:

 One big thing to consider is that core.match is closed dispatch. If you 
 write a function that uses core.match, I can't extend it inside my code. 
 This is something that is possible with both multi-methods and protocols. 

 Timothy

 On Fri, May 15, 2015 at 12:49 PM, Sam Raker sam@gmail.com 
 javascript: wrote:

 The discussion/post-linked-to in 
 https://groups.google.com/d/msg/clojure/eoAp6QVimYI/iipmEJNKdrIJ have 
 got me thinking about protocols  multimethods, which I admittedly have 
 possibly never actually used, now that I think about it. I'm wondering how 
 they differ from core.match[1]. I realize protocols, specifically, have a 
 niche for when you have concrete type information about your data and want 
 better performance. I'm a little less clear about multimethods--in 
 particular, I just considered using multimethods for something, and then 
 ended up reaching for core.match because it seemed more closure-friendly. 

 What, if any, are the benefits of using protocols/multimethods over 
 core.match, or vice versa? When would you reach for one and definitely not 
 the other(s)?


 [1] https://github.com/clojure/core.match

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




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

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Amith George]

Hi Steven,

My bad. You need to invoke the code using the command 

lein run -m rdp.214-intermediate-arr 1 true

The `1` tells it to select a certain input file, (in this case the biggest) 
and the `true` tells it to use the function that internally uses a java 
array (as opposed to the function that internally uses a transient map.) 

The above mentioned command takes around 250secs on my laptop. My apologies 
again, I should have made it clear how to execute the project. 

On Saturday, 16 May 2015 05:48:43 UTC+5:30, Steven Yi wrote:

 Hi Amith,

 I checked out your project from git and just doing 'lein run' I got a 
 reported:

 Elapsed time: 185.651689 msecs

 However, if I modify the -main function in 214_intermediate.clj to wrap 
 the time testing with (doseq [_ (range 20)]), to run the test multiple 
 times, the behavior is much better after the first 9 or so runs, and by the 
 end it is down to:

 Elapsed time: 35.574945 msecs

 I think you might be running into a situation where the VM hasn't run the 
 functions enough times to optimize.  

 Rather than use the time function, you might want to try using 
 criterium[1] to benchmark the code. The site explains all the wonderful 
 things it does to get a good benchmark. 

 Unfortunately, if your data set is small, and you're running a one off 
 calculation like this, I don't know if there's much to improve due to the 
 warmup cost. You could fiddle a bit with VM flags to try to optimize with 
 less calls (I can't recall the flag, but I think the JVM defaults to 
 optimizing after a functions been called 10,000 times).  On the other hand, 
 if you're processing larger datasets, I think it's reassuring that once 
 warmed up, the Clojure code performs pretty well.  

 For reference, this was run on an Macbook Pro 13 early 2011, Core i7 
 2.7ghz. 

 steven

 [1] - https://github.com/hugoduncan/criterium/

 On Friday, May 15, 2015 at 3:59:22 AM UTC-4, Amith George wrote:

 Thanks for the detailed suggestions. Implementing them did bring the 
 execution time down to around 250secs. Though that value is still much 
 longer than 45secs. Could you please verify if I have implemented them 
 correctly?

 Code - 
 https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/4ec02600e025d257a59d76fee0ad0eb01f4785ff/src/rdp/214_intermediate_arr.clj

 project.clj contains the line 

 :jvm-opts ^:replace [-Xms1024m -Xmx1g -server]

0) Switch to Clojure 1.7.0-beta3 - it's faster and some things below 
 are dependent on it for best performance. And use Java 1.8.

 Done. 

1) Parse the lines you're reading directly into longs (Clojure 
 focuses on 64-bit primitives - longs and doubles)

 (defn- read-line-nums
   ([] (read-line-nums (read-line) #(Long/parseLong %1)))
   ([input-line parse-fn]
(if-let [line input-line]
  (- line
   (#(clojure.string/split %1 # ))
   (map parse-fn)

2) Put the longs first into a data structure that preserves the 
 primitive type. The two best options for that here are records (which can 
 have primitive fields) and arrays. I would create a Canvas defrecord with 
 ^long width and height and a Paper defrecord with all ^long fields for 
 example.

 (defrecord Paper [^long color 
   ^long x1  ^long y1
   ^long x2 ^long y2])

 (defrecord Canvas [^long width ^long height])

 (defn- make-paper
   ([^long w ^long h] (make-paper [0 0 0 w h]))
   ([^longs [color x y w h]]
(Paper. color x y (+ x w -1) (+ y h -1

 I had to make the second arity accept a vector, as it seems impossible to 
 create a function accepting more than 4 primitive arguments. Though I 
 suppose I could grouped the args into a `record` of its own?

3) Store the papers in a vector (using transient to create it)

 The `read-input-file` function which creates and stores the papers, it 
 finishes within 20ms. So I didn't bother using a transient. 

4) I suspect visible-color and covered? could probably be tightened 
 up into a reduce over papers or a single loop-recur over papers - can't say 
 I totally get what's happening there.

 The papers vector represents a sheets of papers that have been stacked on 
 top of each other. ie, the last element in the vector is the canvas, and 
 the first element is the topmost sheet. Each sheet is of different 
 dimensions. Depending on the coordinates where they are placed, they may 
 cover a part of the canvas. Different sheets may overlap in the areas they 
 cover and thus we only want to consider the topmost sheet for that area. 

 The `visible-color` function accepts a canvas coordinate and the stack 
 papers and goes through the stack to find the first sheet that covers said 
 coordinate. That papers color will be visible color for that coordinate.

5) In visible-color-frequencies, you could use update instead of 
 get + transient assoc! on the acc map, but this is never going to 

Re: Multimethod or protocol or...? Clojure design feedback

[Luc Préfontaine]

I regroup these name spaces in an api name space and require this name space 
where it makes sense.

You can cut out your APIs as you wish around one or more mutli methods and add
whatever stuff needs to be part of it.

Still manually managed but not scattered everywhere. Never thought of a 
different way
to manage this however.

Luc P.

 Thanks for the feedback guys. Another related Q: The user needs to require 
 the namespace that those defmethods are defined in for the multi to know 
 about it. Presumably each defmethods will be in individual files, meaning 
 the user has to require all those files for the migration tool to work. Is 
 there a cleaner way of make sure that the defmulti knows about those 
 methods?
 
 On Thursday, May 14, 2015 at 7:56:12 PM UTC-4, Jason Marmon wrote:
 
  I'm working on a tool to orchestrate the migration from mongodb to 
  datomic, and i'm looking for a bit of design feedback as i'm new to 
  clojure. 
 
 
  The user needs to provide functions that transform mongodb documents into 
  datomic txes. Do y'all prefer the top or bottom style, or think there's a 
  different way to implement this design that might be better?
  12345678910111213141516171819
 
  ;; Multimethod for transforming data based on the name of the source 
  mongodb collection 
  (defmulti transform identity)
   
  (defmethod transform events [data]
 ;; do something with data
   )
   
  (defmethod transform users [data]
 ;; do something with data
   )
   
  ;;
   
  (defprotocol Collection-Transformer
 (transform [mongo-db document]))
   
  (def user-transformer
   (reify Collection-Transformer
(transform [m d] do stuff)))
 
 
 
 -- 
 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.
 
--
Luc Préfontainelprefonta...@softaddicts.ca sent by ibisMail!

-- 
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: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Steven Yi]

Hi Amith,

I checked out your project from git and just doing 'lein run' I got a 
reported:

Elapsed time: 185.651689 msecs

However, if I modify the -main function in 214_intermediate.clj to wrap the 
time testing with (doseq [_ (range 20)]), to run the test multiple times, 
the behavior is much better after the first 9 or so runs, and by the end it 
is down to:

Elapsed time: 35.574945 msecs

I think you might be running into a situation where the VM hasn't run the 
functions enough times to optimize.  

Rather than use the time function, you might want to try using criterium[1] 
to benchmark the code. The site explains all the wonderful things it does 
to get a good benchmark. 

Unfortunately, if your data set is small, and you're running a one off 
calculation like this, I don't know if there's much to improve due to the 
warmup cost. You could fiddle a bit with VM flags to try to optimize with 
less calls (I can't recall the flag, but I think the JVM defaults to 
optimizing after a functions been called 10,000 times).  On the other hand, 
if you're processing larger datasets, I think it's reassuring that once 
warmed up, the Clojure code performs pretty well.  

For reference, this was run on an Macbook Pro 13 early 2011, Core i7 
2.7ghz. 

steven

[1] - https://github.com/hugoduncan/criterium/

On Friday, May 15, 2015 at 3:59:22 AM UTC-4, Amith George wrote:

 Thanks for the detailed suggestions. Implementing them did bring the 
 execution time down to around 250secs. Though that value is still much 
 longer than 45secs. Could you please verify if I have implemented them 
 correctly?

 Code - 
 https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/4ec02600e025d257a59d76fee0ad0eb01f4785ff/src/rdp/214_intermediate_arr.clj

 project.clj contains the line 

 :jvm-opts ^:replace [-Xms1024m -Xmx1g -server]

0) Switch to Clojure 1.7.0-beta3 - it's faster and some things below 
 are dependent on it for best performance. And use Java 1.8.

 Done. 

1) Parse the lines you're reading directly into longs (Clojure focuses 
 on 64-bit primitives - longs and doubles)

 (defn- read-line-nums
   ([] (read-line-nums (read-line) #(Long/parseLong %1)))
   ([input-line parse-fn]
(if-let [line input-line]
  (- line
   (#(clojure.string/split %1 # ))
   (map parse-fn)

2) Put the longs first into a data structure that preserves the 
 primitive type. The two best options for that here are records (which can 
 have primitive fields) and arrays. I would create a Canvas defrecord with 
 ^long width and height and a Paper defrecord with all ^long fields for 
 example.

 (defrecord Paper [^long color 
   ^long x1  ^long y1
   ^long x2 ^long y2])

 (defrecord Canvas [^long width ^long height])

 (defn- make-paper
   ([^long w ^long h] (make-paper [0 0 0 w h]))
   ([^longs [color x y w h]]
(Paper. color x y (+ x w -1) (+ y h -1

 I had to make the second arity accept a vector, as it seems impossible to 
 create a function accepting more than 4 primitive arguments. Though I 
 suppose I could grouped the args into a `record` of its own?

3) Store the papers in a vector (using transient to create it)

 The `read-input-file` function which creates and stores the papers, it 
 finishes within 20ms. So I didn't bother using a transient. 

4) I suspect visible-color and covered? could probably be tightened up 
 into a reduce over papers or a single loop-recur over papers - can't say I 
 totally get what's happening there.

 The papers vector represents a sheets of papers that have been stacked on 
 top of each other. ie, the last element in the vector is the canvas, and 
 the first element is the topmost sheet. Each sheet is of different 
 dimensions. Depending on the coordinates where they are placed, they may 
 cover a part of the canvas. Different sheets may overlap in the areas they 
 cover and thus we only want to consider the topmost sheet for that area. 

 The `visible-color` function accepts a canvas coordinate and the stack 
 papers and goes through the stack to find the first sheet that covers said 
 coordinate. That papers color will be visible color for that coordinate.

5) In visible-color-frequencies, you could use update instead of get 
 + transient assoc! on the acc map, but this is never going to be terribly 
 fast. Another option here would be to create an array with the max color 
 (you could track that while reading if it's not a well-known answer) and 
 bash the array. That can retain int or long counters and will be *way* 
 faster.

 (defn- visible-color-frequencies-arr
   [{:keys [colors canvas papers]}]
   (let [colorCounts (long-array (count colors))] 
 (reduce 
  (fn [_ ^longs coord]
(if-let [color (visible-color coord papers)]
  (aset-long colorCounts color (+ 1 (aget colorCounts color)))
  

Re: Protocols/multimethods vs core.match

[Timothy Baldridge]

No, it actually compiles down to a pile of ifs, and try/catch/throws (for
backtracking). It's pretty fast, but it won't be as fast as a jump table
for complex matches, that's for sure.

Timothy

On Fri, May 15, 2015 at 5:53 PM, Surgo morgon.kan...@gmail.com wrote:

 core.match compiles down to case, does it not? So the comparisons here are
 similar: http://insideclojure.org/2015/04/27/poly-perf/

 -- Morgon

 On Friday, May 15, 2015 at 2:57:23 PM UTC-4, tbc++ wrote:

 One big thing to consider is that core.match is closed dispatch. If you
 write a function that uses core.match, I can't extend it inside my code.
 This is something that is possible with both multi-methods and protocols.

 Timothy

 On Fri, May 15, 2015 at 12:49 PM, Sam Raker sam@gmail.com wrote:

 The discussion/post-linked-to in
 https://groups.google.com/d/msg/clojure/eoAp6QVimYI/iipmEJNKdrIJ have
 got me thinking about protocols  multimethods, which I admittedly have
 possibly never actually used, now that I think about it. I'm wondering how
 they differ from core.match[1]. I realize protocols, specifically, have a
 niche for when you have concrete type information about your data and want
 better performance. I'm a little less clear about multimethods--in
 particular, I just considered using multimethods for something, and then
 ended up reaching for core.match because it seemed more closure-friendly.

 What, if any, are the benefits of using protocols/multimethods over
 core.match, or vice versa? When would you reach for one and definitely not
 the other(s)?


 [1] https://github.com/clojure/core.match

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




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

Re: Why does the following Clojure code take 10x the time the C# version does? How to improve the Clojure version?

[Steven Yi]

Ah, I see.  Well, I think then you can ignore the stuff about warming
up, as this certainly takes a while to run here:

Elapsed time: 314763.93 msecs

I tried profiling with Yourkit and saw a couple of things to change:

;; I think lte with more than two args ends up being slower than
unrolling out here
;; I also tried type-hinting values from paper to ^long to avoid lte
calls with Number
(defn- covered?
  [[^long canvas-x ^long canvas-y] paper]
  (and (= ^long (:x1 paper) canvas-x ) (= canvas-x ^long (:x2 paper))
   (= ^long (:y1 paper) canvas-y ) (= canvas-y ^long (:y2 paper

;; for the reduce function in visible-color-frequencies-arr
;; using aset instead of aset-long, as it looked like aset-long was
using reflection
 (aset colorCounts color (+ 1 (aget colorCounts color)))

That got it down to:

Elapsed time: 279864.041477 msecs

I suspect you might get improvement too if you change
visible-color-frequencies-arr to use loop-recur instead of reduce
since you're doing a bit of magic there.

Unfortunately I have to stop at the moment as I have to leave on a
trip early in the morning, but hopefully that's useful.

steven


On Fri, May 15, 2015 at 9:07 PM, Amith George strider...@gmail.com wrote:
 Hi Steven,

 My bad. You need to invoke the code using the command

 lein run -m rdp.214-intermediate-arr 1 true

 The `1` tells it to select a certain input file, (in this case the biggest)
 and the `true` tells it to use the function that internally uses a java
 array (as opposed to the function that internally uses a transient map.)

 The above mentioned command takes around 250secs on my laptop. My apologies
 again, I should have made it clear how to execute the project.

 On Saturday, 16 May 2015 05:48:43 UTC+5:30, Steven Yi wrote:

 Hi Amith,

 I checked out your project from git and just doing 'lein run' I got a
 reported:

 Elapsed time: 185.651689 msecs

 However, if I modify the -main function in 214_intermediate.clj to wrap
 the time testing with (doseq [_ (range 20)]), to run the test multiple
 times, the behavior is much better after the first 9 or so runs, and by the
 end it is down to:

 Elapsed time: 35.574945 msecs

 I think you might be running into a situation where the VM hasn't run the
 functions enough times to optimize.

 Rather than use the time function, you might want to try using
 criterium[1] to benchmark the code. The site explains all the wonderful
 things it does to get a good benchmark.

 Unfortunately, if your data set is small, and you're running a one off
 calculation like this, I don't know if there's much to improve due to the
 warmup cost. You could fiddle a bit with VM flags to try to optimize with
 less calls (I can't recall the flag, but I think the JVM defaults to
 optimizing after a functions been called 10,000 times).  On the other hand,
 if you're processing larger datasets, I think it's reassuring that once
 warmed up, the Clojure code performs pretty well.

 For reference, this was run on an Macbook Pro 13 early 2011, Core i7
 2.7ghz.

 steven

 [1] - https://github.com/hugoduncan/criterium/


 On Friday, May 15, 2015 at 3:59:22 AM UTC-4, Amith George wrote:

 Thanks for the detailed suggestions. Implementing them did bring the
 execution time down to around 250secs. Though that value is still much
 longer than 45secs. Could you please verify if I have implemented them
 correctly?

 Code -
 https://github.com/amithgeorge/reddit-dailyprogrammer-clojure/blob/4ec02600e025d257a59d76fee0ad0eb01f4785ff/src/rdp/214_intermediate_arr.clj

 project.clj contains the line

 :jvm-opts ^:replace [-Xms1024m -Xmx1g -server]

0) Switch to Clojure 1.7.0-beta3 - it's faster and some things below
 are dependent on it for best performance. And use Java 1.8.

 Done.

1) Parse the lines you're reading directly into longs (Clojure
 focuses on 64-bit primitives - longs and doubles)

 (defn- read-line-nums
   ([] (read-line-nums (read-line) #(Long/parseLong %1)))
   ([input-line parse-fn]
(if-let [line input-line]
  (- line
   (#(clojure.string/split %1 # ))
   (map parse-fn)

2) Put the longs first into a data structure that preserves the
 primitive type. The two best options for that here are records (which can
 have primitive fields) and arrays. I would create a Canvas defrecord with
 ^long width and height and a Paper defrecord with all ^long fields for
 example.

 (defrecord Paper [^long color
   ^long x1  ^long y1
   ^long x2 ^long y2])

 (defrecord Canvas [^long width ^long height])

 (defn- make-paper
   ([^long w ^long h] (make-paper [0 0 0 w h]))
   ([^longs [color x y w h]]
(Paper. color x y (+ x w -1) (+ y h -1

 I had to make the second arity accept a vector, as it seems impossible to
 create a function accepting more than 4 primitive arguments. Though I
 suppose I could grouped the args into a `record` of its own?

re: functional == slow

[Raoul Duke]

at least, it often feels like that is the practical reality cf.
clojure vs. java; f# vs. c#; haskell vs. c -- oh, wait a minute:
http://www.cs.ru.nl/P.Achten/IFL2013/symposium_proceedings_IFL2013/ifl2013_submission_20.pdf

-- 
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: Code Review

[Sven Richter]

Thanks to both of you, this looks more like what I am used to with clojure. 
The transpose function is the trick here :-)

Best Regards,
Sven

Am Freitag, 15. Mai 2015 10:35:11 UTC+2 schrieb Ray Miller:

 If I've understood the problem correctly, you can simplify the code by 
 implementing a transpose function: 

 (defn transpose [xs] (apply map vector xs)) 

 Then define a wanted? function for filtering the lines you want to 
 include: 

 (defn wanted? [xs] (some zero? xs)) 

 ...and a helper function to left-pad a vector with zeroes: 

 (defn lpad [n xs] (vec (concat (repeat (- n (count xs)) 0) xs))) 

 So your main function would look something like: 

 (defn process [xs] (let [n (count (first xs))] (vec (map (partial lpad 
 n) (transpose (filter wanted? (transpose xs))) 

 On 15 May 2015 at 09:01, Sven Richter sve...@googlemail.com javascript: 
 wrote: 
  HI, 
  
  I just posted a question to stackoverflows code review 
  page:
 http://codereview.stackexchange.com/questions/90809/remove-lines-from-a-2d-vec-in-clojure
  
  
  As there is not much traffic regarding clojure I also double post to 
 this 
  list in the hope to get some good answers. You might respond here or 
 there, 
  whatever you like best. 
  
  I have some code here that I am very unhappy with. The task I am trying 
 to 
  accomplish is this. 
  
  Given a 2d vec like this: 
  
  [[0 2 0] [1 3 5] [3 3 0]] 
  which can contain positive ints including zero I want to remove all 
 _lines_ 
  that are greater zero. 
  Whereas the definition of _line_ is the following: 
  A _line_ is represented by the position n in every vec inside the 2d 
 vec. So 
  my example above has three lines: 
  
  [0 1 3], [2 3 3] and [0 5 0]. 
  
  The line that I want to remove from it according to my algortihm is **[2 
 3 
  3]** because every element is greater than zero. 
  
  So my 2d vec would now look like this: 
  
  [[0 0] [1 5] [3 0]] 
  
  And finally I want to pad the vecs to their original size filling them 
 with 
  zero for every removed line, so that it looks finally like this: 
  
  [[0 0 0] [0 1 5] [0 3 0]] 
  
  This is what I came up with: 
  
  (defn in? 
true if seq contains elm 
[seq elm] 
(some #(= elm %) seq)) 
  
  (defn not-in? 
true if seq does not contain elm 
[seq elm] 
(not (in? seq elm))) 
  
  (defn all-greater-zero-at 
Given a 2-d vec [[0 1] [0 2]] return true if all elements at 'at' 
 are 
greater than zero 
[v at] 
(not-in? (map #(if ( (nth % at) 0) true false) v) false)) 
  
  (defn to-be-removed 
Returns a seq of positions to be removed (0 3 4) 
[v width] 
(reduce (fn [a b] (if (all-greater-zero-at v b) (conj a b) a)) [] 
  (range width))) 
  
  (defn remove-at 
Removes an element from a 1d vec 
[v at] 
(into [] (concat (subvec v 0 at) (subvec v (+ at 1) (count v) 
  
  (defn insert-at 
inserts an element into a 1d vec 
[v elm at] 
(into [] (concat (subvec v 0 at) elm (subvec v at (count v) 
  
  (defn remove-and-replace-all-at 
[v at] 
(map #(insert-at (remove-at % at) [0] at) v)) 
  
  (defn replace-full-by-zero [v width] 
(reduce (fn [a b] (remove-and-replace-all-at a b)) v 
 (to-be-removed v 
  width))) 
  
  (defn remove-zeros [v at] 
(reduce (fn [a b] (conj a (remove-at b at))) [] v)) 
  
  (defn fill-with-zeros 
Takes a 2d vec and pads ith with zeros up to width 
[v width] 
(map #(into [] (concat (take (- width (count (first v))) (repeat 
 0)) 
  %)) v)) 
  
  (defn clean-grid 
removes all full lines 
[fbz tbr] 
(loop [acc fbz tbr tbr i 0] 
  (if (empty? tbr) 
acc 
(recur (remove-zeros acc (- (first tbr) i)) (rest tbr) (inc 
 i) 
  
  (defn remove-full-lines [v width] 
(let [fbz (replace-full-by-zero v width) 
  tbr (to-be-removed v width) 
  cleaned-grid (clean-grid fbz tbr)] 
  (into [] (fill-with-zeros cleaned-grid width 
  
  This seems like a lot of code for such a simple algorithm and I assume 
  there are a lot of better ways to do that, but just did not come up with 
 a 
  better one, so, please, go ahead and fix it, if you want to :-) 
  
  Best Regards, 
  Sven 
  
  -- 
  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 

[ANN] darwin and algebolic - genetic algorithms, and evolving mathematics

[Jony Hudson]

Hi All,

 it's my pleasure to share with you two libraries: darwin and algebolic.

Algebolic is a library for evolving mathematical expressions. You can use 
it to perform what's known as symbolic regression, where a symbolic 
mathematical expression is found that fits a given dataset. More generally, 
you can use it to evolve mathematical expressions that optimise any score 
function. The expressions are implemented so they can be very quickly 
evaluated, as can their derivatives which is useful in more advanced 
applications. We use it in my research lab, for example, to evolve laws of 
physics directly from data.

Repository: https://github.com/JonyEpsilon/algebolic
Getting started example: 
http://viewer.gorilla-repl.org/view.html?source=githubuser=JonyEpsilonrepo=algebolicpath=ws/demo/intro.clj

Algebolic is powered by ...

Darwin is a flexible framework for programming genetic algorithms, aimed at 
research applications. It is representation agnostic, working just as well 
for simple GA examples as it does for complex genetic programming problems. 
It can be configured to perform both single- and multi-objective 
optimisation, including the SPEA2 algorithm. It has facility for adaptive 
evolution where the run parameters evolve in response to changes in the 
population.

Repository: https://github.com/JonyEpsilon/darwin
Getting started example: 
http://viewer.gorilla-repl.org/view.html?source=githubuser=JonyEpsilonrepo=darwinpath=ws/demo.clj


Some of the code is research-quality and in particular the core data 
structures in Darwin are a bit suspect. And the documentation is a bit 
sparse in places. But it works and maybe someone will find it useful :-)

Enjoy!


Jony

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

Protocols/multimethods vs core.match

[Sam Raker]

The discussion/post-linked-to 
in https://groups.google.com/d/msg/clojure/eoAp6QVimYI/iipmEJNKdrIJ have 
got me thinking about protocols  multimethods, which I admittedly have 
possibly never actually used, now that I think about it. I'm wondering how 
they differ from core.match[1]. I realize protocols, specifically, have a 
niche for when you have concrete type information about your data and want 
better performance. I'm a little less clear about multimethods--in 
particular, I just considered using multimethods for something, and then 
ended up reaching for core.match because it seemed more closure-friendly. 

What, if any, are the benefits of using protocols/multimethods over 
core.match, or vice versa? When would you reach for one and definitely not 
the other(s)?


[1] https://github.com/clojure/core.match

-- 
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: Protocols/multimethods vs core.match

[Timothy Baldridge]

One big thing to consider is that core.match is closed dispatch. If you
write a function that uses core.match, I can't extend it inside my code.
This is something that is possible with both multi-methods and protocols.

Timothy

On Fri, May 15, 2015 at 12:49 PM, Sam Raker sam.ra...@gmail.com wrote:

 The discussion/post-linked-to in
 https://groups.google.com/d/msg/clojure/eoAp6QVimYI/iipmEJNKdrIJ have got
 me thinking about protocols  multimethods, which I admittedly have
 possibly never actually used, now that I think about it. I'm wondering how
 they differ from core.match[1]. I realize protocols, specifically, have a
 niche for when you have concrete type information about your data and want
 better performance. I'm a little less clear about multimethods--in
 particular, I just considered using multimethods for something, and then
 ended up reaching for core.match because it seemed more closure-friendly.

 What, if any, are the benefits of using protocols/multimethods over
 core.match, or vice versa? When would you reach for one and definitely not
 the other(s)?


 [1] https://github.com/clojure/core.match

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




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

Re: Multimethod or protocol or...? Clojure design feedback

[Jason Marmon]

Thanks for the feedback guys. Another related Q: The user needs to require 
the namespace that those defmethods are defined in for the multi to know 
about it. Presumably each defmethods will be in individual files, meaning 
the user has to require all those files for the migration tool to work. Is 
there a cleaner way of make sure that the defmulti knows about those 
methods?

On Thursday, May 14, 2015 at 7:56:12 PM UTC-4, Jason Marmon wrote:

 I'm working on a tool to orchestrate the migration from mongodb to 
 datomic, and i'm looking for a bit of design feedback as i'm new to 
 clojure. 


 The user needs to provide functions that transform mongodb documents into 
 datomic txes. Do y'all prefer the top or bottom style, or think there's a 
 different way to implement this design that might be better?
 12345678910111213141516171819

 ;; Multimethod for transforming data based on the name of the source mongodb 
 collection 
 (defmulti transform identity)
  
 (defmethod transform events [data]
;; do something with data
  )
  
 (defmethod transform users [data]
;; do something with data
  )
  
 ;;
  
 (defprotocol Collection-Transformer
(transform [mongo-db document]))
  
 (def user-transformer
  (reify Collection-Transformer
   (transform [m d] do stuff)))



-- 
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] darwin and algebolic - genetic algorithms, and evolving mathematics

[Lee Spector]

Fantastic to see this Jony!

I look forward to checking it out in detail.

Those interested in genetic programming in Clojure might also want to check out:

- https://github.com/lspector/gp (minimalist tree-based genetic programming 
implementation, written for educational purposes but maybe useful for more)

- https://github.com/lspector/Clojush (long-running, active research project on 
an alternative approach to genetic programming)

If anyone else is working in this space I'd love to hear from you too.

 -Lee


 On May 15, 2015, at 4:57 PM, Jony Hudson jonyepsi...@gmail.com wrote:
 
 Hi All,
 
  it's my pleasure to share with you two libraries: darwin and algebolic.
 
 Algebolic is a library for evolving mathematical expressions. You can use it 
 to perform what's known as symbolic regression, where a symbolic mathematical 
 expression is found that fits a given dataset. More generally, you can use it 
 to evolve mathematical expressions that optimise any score function. The 
 expressions are implemented so they can be very quickly evaluated, as can 
 their derivatives which is useful in more advanced applications. We use it in 
 my research lab, for example, to evolve laws of physics directly from data.
 
 Repository: https://github.com/JonyEpsilon/algebolic
 Getting started example: 
 http://viewer.gorilla-repl.org/view.html?source=githubuser=JonyEpsilonrepo=algebolicpath=ws/demo/intro.clj
 
 Algebolic is powered by ...
 
 Darwin is a flexible framework for programming genetic algorithms, aimed at 
 research applications. It is representation agnostic, working just as well 
 for simple GA examples as it does for complex genetic programming problems. 
 It can be configured to perform both single- and multi-objective 
 optimisation, including the SPEA2 algorithm. It has facility for adaptive 
 evolution where the run parameters evolve in response to changes in the 
 population.
 
 Repository: https://github.com/JonyEpsilon/darwin
 Getting started example: 
 http://viewer.gorilla-repl.org/view.html?source=githubuser=JonyEpsilonrepo=darwinpath=ws/demo.clj
 
 
 Some of the code is research-quality and in particular the core data 
 structures in Darwin are a bit suspect. And the documentation is a bit sparse 
 in places. But it works and maybe someone will find it useful :-)
 
 Enjoy!
 
 
 Jony

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