Re: Trouble with type hints
On Feb 16, 6:20 am, Nick wrote: > (let [ newv1 (time (doall (map (fn [v u I] (+ ^java.lang.Double v (* > 0.5 (+ (* (+ (* 0.04 ^java.lang.Double v) 5) ^java.lang.Double v) 140 > (- ^java.lang.Double u) ^java.lang.Double I v u I))) > newv (time (doall (map (fn [v u I] (+ v (* 0.5 (+ (* (+ (* 0.04 v) > 5) v) 140 (- u) I newv1 u I)))] > > I've tried without type hints, with type hints, different ways of > doing the type hints, but I cannot explain the results that I'm > seeing. With all of the variations I've tried, I've always seen > timing like this: > > "Elapsed time: 49.876243 msecs" > "Elapsed time: 0.179701 msecs" > > What am I missing here? Is the compiler getting some advantage to > executing the same function twice that cannot be gained in the first > execution? Since nobody has replied so far: One explanation I could imagine is that your type-hints in the first invocation force the compiler to use object types for all the nitty-gritty calculations, whereas the second invocation is able to use primitives for calculations, having to box them only when the final sequence is produced. I'm not an expert on Clojure performance though, this is just a guess. Have you tried type-hinting your second invocation instead of the first? What do the timings become? -- 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
Tursas chess engine
I've made a simple chess engine in Clojure. This is my first larger program in functional programming so I'd like to have some feedback about it. I'd be most interested in ways to make it more idiomatic functional code. Also any performance tweaks would be nice. Currently the engine can search moves up to depth 4 in reasonable time. I think searching to depth 6 or 7 could be possible by tweaking the code. I'm still figuring out a good way to add error detection for the game- repl. Now if user gives wrong args to command it crashes the whole program. The project it hosted at github: https://github.com/zmyrgel/tursas -- 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: Trouble with type hints
On Fri, Feb 18, 2011 at 7:03 AM, Daniel Werner wrote: > On Feb 16, 6:20 am, Nick wrote: >> (let [ newv1 (time (doall (map (fn [v u I] (+ ^java.lang.Double v (* >> 0.5 (+ (* (+ (* 0.04 ^java.lang.Double v) 5) ^java.lang.Double v) 140 >> (- ^java.lang.Double u) ^java.lang.Double I v u I))) >> newv (time (doall (map (fn [v u I] (+ v (* 0.5 (+ (* (+ (* 0.04 v) >> 5) v) 140 (- u) I newv1 u I)))] >> >> I've tried without type hints, with type hints, different ways of >> doing the type hints, but I cannot explain the results that I'm >> seeing. With all of the variations I've tried, I've always seen >> timing like this: >> >> "Elapsed time: 49.876243 msecs" >> "Elapsed time: 0.179701 msecs" >> >> What am I missing here? Is the compiler getting some advantage to >> executing the same function twice that cannot be gained in the first >> execution? > > Since nobody has replied so far: One explanation I could imagine is > that your type-hints in the first invocation force the compiler to use > object types for all the nitty-gritty calculations, whereas the second > invocation is able to use primitives for calculations, having to box > them only when the final sequence is produced. Yes, that's exactly right. Some operators like + Clojure's compiler knows to inline and then they don't have to box primitives. The type hints force boxing in this case. -- 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: defrecord/deftype ...
One purpose of defrecord was to be interchangeable with maps, so that you can prototype with maps, then switch to defrecord for better performance without changing much code. If you use constructor functions to create instances of your records/maps, you hardly have to change anything at all. Another purpose of defrecord (and deftype) is to support new types that implement protocols. Defrecord adds real type information to maps (accessible through the `type` function) but this was already possible with metadata. -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Java Agent Based Modeling Systems and Clojure
I don't know much about Agent-Based Modeling, but is it possible you could use Clojure's built-in features, like Agents and Refs, for your application? The old "ants" demo in Clojure is a simple agent-based simulation. -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Trouble with type hints
I've actually tried with and without type hinting and end up with similar performance numbers. I haven't tried type hinting the second execution. On Feb 18, 7:49 am, Ken Wesson wrote: > On Fri, Feb 18, 2011 at 7:03 AM, Daniel Werner > > > > wrote: > > On Feb 16, 6:20 am, Nick wrote: > >> (let [ newv1 (time (doall (map (fn [v u I] (+ ^java.lang.Double v (* > >> 0.5 (+ (* (+ (* 0.04 ^java.lang.Double v) 5) ^java.lang.Double v) 140 > >> (- ^java.lang.Double u) ^java.lang.Double I v u I))) > >> newv (time (doall (map (fn [v u I] (+ v (* 0.5 (+ (* (+ (* 0.04 v) > >> 5) v) 140 (- u) I newv1 u I)))] > > >> I've tried without type hints, with type hints, different ways of > >> doing the type hints, but I cannot explain the results that I'm > >> seeing. With all of the variations I've tried, I've always seen > >> timing like this: > > >> "Elapsed time: 49.876243 msecs" > >> "Elapsed time: 0.179701 msecs" > > >> What am I missing here? Is the compiler getting some advantage to > >> executing the same function twice that cannot be gained in the first > >> execution? > > > Since nobody has replied so far: One explanation I could imagine is > > that your type-hints in the first invocation force the compiler to use > > object types for all the nitty-gritty calculations, whereas the second > > invocation is able to use primitives for calculations, having to box > > them only when the final sequence is produced. > > Yes, that's exactly right. Some operators like + Clojure's compiler > knows to inline and then they don't have to box primitives. The type > hints force boxing in this case. -- 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: Trouble with type hints
> Is there something besides type-hinting that I'm missing? Is there any chance that you can make a sample data set/complete script available? That would make it easier to try different things and figure out where the problem is. Sincerely, Daniel Solano Gómez pgp40moegLknA.pgp Description: PGP signature
Re: defrecord/deftype ...
Hi Stuart - I am very much still learning Clojure and havent waded into defrecord, etc. Could you provide an example of how you wold start with a map and shift to a defrecord in the future? Thanks Base On Feb 18, 11:16 am, Stuart Sierra wrote: > One purpose of defrecord was to be interchangeable with maps, so that you > can prototype with maps, then switch to defrecord for better performance > without changing much code. If you use constructor functions to create > instances of your records/maps, you hardly have to change anything at all. > > Another purpose of defrecord (and deftype) is to support new types that > implement protocols. > > Defrecord adds real type information to maps (accessible through the `type` > function) but this was already possible with metadata. > > -Stuart Sierra > clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: defrecord/deftype ...
Hi Base,
It's easy, because instances of defrecord behave identically to maps. Say
you have a lot of "person" records that look like this:
{:first-name "Stuart", :last-name "Sierra", :location "NYC"}
You might write a constructor function to create these maps:
(defn person [& options]
(apply hash-map options))
You use the `person` function to create "person" maps, and you manipulate
them using Clojure's map functions (assoc, dissoc, get, etc.). You can
easily add or remove keys in the map as you develop your application.
Then you want "person" records to be smaller and faster. So you write:
(defrecord Person [first-name last-name location])
(defn person [& options]
(let [{:keys [first-name last-name location]} options]
(Person. first-name last-name location)))
Poof! None of your existing code has to change how it creates and
manipulates "person"s, but all your maps are now records.
-Stuart Sierra
clojure.com
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Functional program design concepts
For examples of polymorphism mixing Java and Clojure, try my article on Developer Works: http://www.ibm.com/developerworks/java/library/j-clojure-protocols/ -Stuart Sierra clojure.com -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: defrecord/deftype ...
Thank you Stuart! This makes perfect sense and is quite elegant.
So is performance the only compelling reason to do this? I am assuming
there are times that maps are 'good enough', but would you say that if
you ever have a defined data structure you would advise to use
defrecord to gain this increase in speed? Are there some things that
you can do with maps that you cannot do with defrecord?
On Feb 18, 3:05 pm, Stuart Sierra wrote:
> Hi Base,
>
> It's easy, because instances of defrecord behave identically to maps. Say
> you have a lot of "person" records that look like this:
>
> {:first-name "Stuart", :last-name "Sierra", :location "NYC"}
>
> You might write a constructor function to create these maps:
>
> (defn person [& options]
> (apply hash-map options))
>
> You use the `person` function to create "person" maps, and you manipulate
> them using Clojure's map functions (assoc, dissoc, get, etc.). You can
> easily add or remove keys in the map as you develop your application.
>
> Then you want "person" records to be smaller and faster. So you write:
>
> (defrecord Person [first-name last-name location])
>
> (defn person [& options]
> (let [{:keys [first-name last-name location]} options]
> (Person. first-name last-name location)))
>
> Poof! None of your existing code has to change how it creates and
> manipulates "person"s, but all your maps are now records.
>
> -Stuart Sierra
> clojure.com
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: defrecord/deftype ...
On Fri, Feb 18, 2011 at 5:31 PM, Base wrote: > Are there some things that you can do with maps that you cannot do > with defrecord? Round-trip them through prn/read without them turning into something else. -- 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: defrecord/deftype ...
For one, the type of a record is not as malleable as the other attributes of
the record. It's less dynamic.
2011/2/18 Base
> Thank you Stuart! This makes perfect sense and is quite elegant.
>
> So is performance the only compelling reason to do this? I am assuming
> there are times that maps are 'good enough', but would you say that if
> you ever have a defined data structure you would advise to use
> defrecord to gain this increase in speed? Are there some things that
> you can do with maps that you cannot do with defrecord?
>
> On Feb 18, 3:05 pm, Stuart Sierra wrote:
> > Hi Base,
> >
> > It's easy, because instances of defrecord behave identically to maps.
> Say
> > you have a lot of "person" records that look like this:
> >
> > {:first-name "Stuart", :last-name "Sierra", :location "NYC"}
> >
> > You might write a constructor function to create these maps:
> >
> > (defn person [& options]
> > (apply hash-map options))
> >
> > You use the `person` function to create "person" maps, and you manipulate
> > them using Clojure's map functions (assoc, dissoc, get, etc.). You can
> > easily add or remove keys in the map as you develop your application.
> >
> > Then you want "person" records to be smaller and faster. So you write:
> >
> > (defrecord Person [first-name last-name location])
> >
> > (defn person [& options]
> > (let [{:keys [first-name last-name location]} options]
> > (Person. first-name last-name location)))
> >
> > Poof! None of your existing code has to change how it creates and
> > manipulates "person"s, but all your maps are now records.
> >
> > -Stuart Sierra
> > clojure.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 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
First N unique random floats from a lazy seq
I want to get first N (for example 100) unique random floats. Here is what I have. (defn rand-flt [max-flt] (format "%.2f" (rand max-flt))) (defn gen-rand-flts [max-flt] (lazy-seq (cons (rand-flt max-flt) (gen-rand-flts max-flt (defn get-n-floats [max-float, how-many] (let [tf-fun (fn [] (take how-many (gen-rand-flts max-float)))] (loop [sof (set (tf-fun))] (if (> (count sof) (dec how-many)) (take how-many sof) (recur (set (concat sof (tf-fun (get-n-floats 100.0 10) This works but I feel that should be more idiomatic solution for get-n- floats. I have tried take-while, some, even read about delay/force but couldn't come up with a shorter alternative; main problem is realizing lazy seq. Any suggestions? -- 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
First N unique random floats from a lazy seq
I want to get first N (for example 100) unique random floats. Here is what I have. (defn rand-flt [max-flt] (format "%.2f" (rand max-flt))) (defn gen-rand-flts [max-flt] (lazy-seq (cons (rand-flt max-flt) (gen-rand-flts max-flt (defn get-n-floats [max-float, how-many] (let [tf-fun (fn [] (take how-many (gen-rand-flts max-float)))] (loop [sof (set (tf-fun))] (if (> (count sof) (dec how-many)) (take how-many sof) (recur (set (concat sof (tf-fun (get-n-floats 100.0 10) This works but I feel that should be more idiomatic solution for get-n- floats. I have tried take-while, some, even read about delay/force but couldn't come up with a shorter alternative; main problem is realizing lazy seq. Any suggestions? -- 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: First N unique random floats from a lazy seq
user=> (take 100 (distinct (repeatedly #(rand-int 200 (100 55 65 188 90 150 144 72 137 74 187 158 163 28 140 146 111 116 135 88 29 81 36 173 149 79 16 105 82 162 60 20 49 50 91 176 165 3 56 22 9 85 44 101 33 134 186 128 141 103 92 143 123 23 129 83 80 5 172 179 166 167 66 195 99 164 38 138 148 130 6 155 32 175 120 18 197 190 78 19 46 7 77 68 76 189 63 27 4 43 24 183 122 51 95 157 153 156 199 110) Adjust this for whatever random-generator you want to use. On Feb 18, 3:31 pm, Vitaly Peressada wrote: > I want to get first N (for example 100) unique random floats. Here is > what I have. > > (defn rand-flt [max-flt] > (format "%.2f" (rand max-flt))) > > (defn gen-rand-flts [max-flt] > (lazy-seq (cons (rand-flt max-flt) (gen-rand-flts max-flt > > (defn get-n-floats [max-float, how-many] > (let [tf-fun (fn [] (take how-many (gen-rand-flts max-float)))] > (loop [sof (set (tf-fun))] > (if (> (count sof) (dec how-many)) > (take how-many sof) > (recur (set (concat sof (tf-fun > > (get-n-floats 100.0 10) > > This works but I feel that should be more idiomatic solution for get-n- > floats. I have tried take-while, some, even read about delay/force but > couldn't come up with a shorter alternative; main problem is realizing > lazy seq. Any suggestions? -- 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: First N unique random floats from a lazy seq
On Fri Feb 18 15:38 2011, Alan wrote: > user=> (take 100 (distinct (repeatedly #(rand-int 200 > (100 55 65 188 90 150 144 72 137 74 187 158 163 28 140 146 111 116 135 > 88 29 81 36 173 149 79 16 105 82 162 60 20 49 50 91 176 165 3 56 22 9 > 85 44 101 33 134 186 128 141 103 92 143 123 23 129 83 80 5 172 179 166 > 167 66 195 99 164 38 138 148 130 6 155 32 175 120 18 197 190 78 19 46 > 7 77 68 76 189 63 27 4 43 24 183 122 51 95 157 153 156 199 110) > > Adjust this for whatever random-generator you want to use. To realise the sequence and keep the results, use (doall). Hence: (doall (take 100 (distinct (repeatedly #(format "%.2f" (rand 100.0)) Sincerely, Daniel Solano Gómez pgp9eJJGtbuU0.pgp Description: PGP signature
Re: First N unique random floats from a lazy seq
Thanks, Alan and Daniel. That is exactly what I was looking for. On Feb 18, 6:53 pm, Daniel Solano Gomez wrote: > On Fri Feb 18 15:38 2011, Alan wrote: > > > user=> (take 100 (distinct (repeatedly #(rand-int 200 > > (100 55 65 188 90 150 144 72 137 74 187 158 163 28 140 146 111 116 135 > > 88 29 81 36 173 149 79 16 105 82 162 60 20 49 50 91 176 165 3 56 22 9 > > 85 44 101 33 134 186 128 141 103 92 143 123 23 129 83 80 5 172 179 166 > > 167 66 195 99 164 38 138 148 130 6 155 32 175 120 18 197 190 78 19 46 > > 7 77 68 76 189 63 27 4 43 24 183 122 51 95 157 153 156 199 110) > > > Adjust this for whatever random-generator you want to use. > > To realise the sequence and keep the results, use (doall). > > Hence: > (doall (take 100 (distinct (repeatedly #(format "%.2f" (rand 100.0)) > > Sincerely, > > Daniel Solano Gómez > > application_pgp-signature_part > < 1KViewDownload -- 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: First N unique random floats from a lazy seq
On Feb 19, 12:38 am, Alan wrote: > user=> (take 100 (distinct (repeatedly #(rand-int 200 Nitpick: the distinct call may be useful in some circumstances, but if you want a truly random sequence, you definitely do not want it there. Joost. -- 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
deploying application updates to end users
Has anyone had any experience in the best way to deploy updates to end users who have no programming experience? The application basically consists of a src directory, and a bat file which runs 'lein run' to start the program. It also consists of some extraneous files that have to be installed on the system under another program directory. The simplest method would be to take zip files and unzip them to the appropriate place. But i was wondering about things like 'uninstalling' updates, automatic updates from (free hosting?) website, better 'patch' formats, etc. -- 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
[ANN] Openar, a Clojure environment
Hi, I created a Swing-based Clojure environment written in Clojure. It's called Openar. It's still immature and has basic features necessary for self-maintaining on Mac OS X only. Yet I hope even this version helps people who are looking for a casual Clojure box. Here is the link to the repo: https://github.com/ksuzuki/Openar/ Your questions and suggestions are welcome. Please post them to the Openar Google Group (http://groups.google.com/group/openar). Sincerely, Kei Suzuki -- 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: First N unique random floats from a lazy seq
Of course. But, to counter-nitpick, the OP asked for "the first N
*unique* random floats". Hence distinct.
I might point out, though, that getting floats and truncating them to
two digits is wasting a lot of the processor's time, and yours in
writing it. I'd get integers first and then divide to turn them into
floats:
(map #(str (/ % 100.0)) (take 100 (distinct (repeatedly #(rand-int
1)
("36.35" "92.07" "41.02" "61.19" "12.19" "54.07" "11.39" "41.55"
"25.87" "20.84" "88.42" "74.26" "24.87" "75.45" "60.82" "1.06" "68.24"
"54.36" "89.64" "63.99" "94.73" "79.75" "40.96" "90.57" "79.56"
"59.18" "65.45" "24.18" "49.95" "13.15" "5.88" "38.99" "14.98" "93.17"
"38.41" "82.29" "53.7" "82.61" "30.39" "67.77" "96.84" "30.41" "28.42"
"3.63" "32.23" "53.97" "73.96" "76.15" "61.65" "61.51" "80.41" "25.73"
"37.77" "86.59" "95.9" "45.85" "13.95" "97.85" "18.63" "7.59" "46.51"
"45.56" "28.37" "62.39" "99.77" "33.22" "46.36" "3.77" "17.05" "57.38"
"38.95" "75.52" "37.72" "41.4" "35.4" "97.82" "59.82" "0.38" "39.27"
"45.74" "70.51" "13.24" "74.38" "55.07" "92.69" "45.54" "21.53"
"49.42" "24.82" "61.68" "70.05" "79.37" "83.37" "89.07" "29.4" "39.66"
"92.49" "48.23" "20.7" "83.6")
On Feb 18, 4:19 pm, Joost wrote:
> On Feb 19, 12:38 am, Alan wrote:
>
> > user=> (take 100 (distinct (repeatedly #(rand-int 200
>
> Nitpick: the distinct call may be useful in some circumstances, but if
> you want a truly random sequence, you definitely do not want it there.
>
> Joost.
--
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
