Re: Past and future of data.generators
For the record, I just did some simple speed comparisons of sampling functions from Incanter, data.generators, and bigml/sampling, and data.generators performs very well. It was fastest in some tests. -- 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: Past and future of data.generators
For the record, after doing some simple speed comparisons of ampling functions from Incanter, data.generators, and bigml/sampling (using Criterium, and making sure to doall lazy sequences), it appears that data.generators performs very well in some situations. -- 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: Advice on managing random number generators across threads
On Saturday, June 7, 2014 7:09:53 PM UTC-5, Alexander Hudek wrote: > > Keep in mind that there could be accuracy reasons why you might want to > use multiple random number generators (aka multiple streams). See the > section "Single Versus Multiple Streams" here: > > http://www.cse.msu.edu/~cse808/CSIM_Notes03/cse808/html_c/16random.htm > Very nice--thanks. I had never heard of this issue, but it makes sense. > Also, the built in java random number generator is ok, but not > state-of-the-art in terms of quality. A more popular high quality generator > is the Mersenne twister. There are several java implementations available. > That's what I thought, and I was leaning toward using a Mersenne twister. An additional advantage of sampling libraries like data.generators and bigml/sampling that allow one to specify the RNG is the ability to use a different RNG algorithm. -- 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.
Use Nodejs modules in Clojurescript code that targets browsers?
Is there any way to use nodejs modules (the browserifiable ones) in Clojurescript code that targets browsers? AutoSaved textareas Restored textareas Cleared AutoSaved data AutoSaved textarea data available -- 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: Eval-ing a map expression in Emacs Live doesn't seem to work
On Sat, Jun 7, 2014 at 4:27 PM, gvim wrote: > Thanks, that's what I needed. I realise I've muddled C-x C-e with a > command within Light Table which works with the closing paren of an > s-expression. In Emacs you have to be on the next line following the > closing paren. Got it now. The road to Emacs/Clojure enlightenment is once > more open :) > I'm glad that was helpful. I find I use C-c C-c most often (evals the top level form you're currently in) and C-c C-k (evals the whole buffer) most. I recently started playing with Cursive (for IntelliJ) which is pretty great. I can't quite convince myself to live in IntelliJ though, so I'm back in Emacs right now - one thing I'd love is if eval-ing a form in a file buffer generated output in the repl as it does in Cursive - the whole form is echo'd and the returned value below, as if it had been typed by hand. One thing that Emacs Live does out of the box by default is use eval-sexp-fu, which lights up the evaluated code. That's an awesome hack, which makes the missing cursive-like echo a bit more tolerable. I nicked Sam's code (for making eval-sexp-fu work with clojure) for my own config, when not using Emacs Live. There was some discussion here a while ago about LightTable's in-buffer eval output, which Emacs can't quite do as nicely yet. These seemingly small and superficial features can make a huge difference to flow. cheers, J -- 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: Advice on managing random number generators across threads
Keep in mind that there could be accuracy reasons why you might want to use multiple random number generators (aka multiple streams). See the section "Single Versus Multiple Streams" here: http://www.cse.msu.edu/~cse808/CSIM_Notes03/cse808/html_c/16random.htm Also, the built in java random number generator is ok, but not state-of-the-art in terms of quality. A more popular high quality generator is the Mersenne twister. There are several java implementations available. On Friday, June 6, 2014 11:33:04 PM UTC-4, Mars0i wrote: > > Wow. Linus, thanks for the very detailed answer. > > It sounds as your view is that there's no problem with the logic of my > proposed solution, but it seems wasteful to create 100 RNGs, when I don't > actually need to have so many of them. Your solutions provide ways to get > the same result without maintaining so many RNG objects in a simulation > run. Is that roughly correct? > > On Friday, June 6, 2014 2:26:25 PM UTC-5, Linus Ericsson wrote: >> >> (I think your stepwise problem is better to be solved without agents, see >> below.) >> >> I realized that the *rng* actually is conflated, it keeps both the state >> for the random number generator AND the algorithm used for the random >> number generation. This is usually not a problem, since the state-size and >> usage is dependent on the particular random number generator, but it >> becomes a problem when we need to separate and multithread things >> > > Interesting point. OK. But seem my comment below about sharing of code > between RNG objects. > > >> One solution would be to either re-implement the algorithm (by Knuth) >> used in the original Sun Java random implementation, or use the >> experimental library Four [1] by Gary Fredericks that does exactly this. >> > > Four looks very nice. Its stateless RNGs return a new RNG, rather than an > RNG state, btw: > (class (rs/java-random 1001)) > ;==> four.stateless.JavaRandom > (map class (rs/next-long (rs/java-random 1001))) > ;==> (java.lang.Long four.stateless.JavaRandom) > I can see how this might be useful, though. > > What you would like to do is to be able to feed the rng-algorithm with the >> state (it is just a 64 bit long), and simply take the random-result >> generated from it, and store the state in the agent together with the rest >> of the simulation state. >> >> Dubious Speculations: >> This makes it necessary to know that the agents are called in the same >> order (if the influence on each other). >> > > > >> Given the non-guarantee of ordering in the nature of Java Threads and how >> agents rely on them I don't think you can expect your result to be >> reproducible. >> > > Right. I can guarantee the order in which the random numbers are used > when I use map to cause each person to do its work, but I assume that I > can't guarantee this order when I use pmap. > > >> Here I assume that the incoming calls to agents aren't guaranteed to >> strictly ordered among different agents, even though the agents reside in >> one of two thread-pools (the send- vs. send-off pools). If two agents sent >> messages that arrived a third agent in different order, the rng-state would >> differ between the runs). Please correct me if I'm wrong on this one. >> > > No, there's no issue about the order in which messages are received, I > believe. Communication is effectively simultaneous, because all sending > happens in one step, and all receiving happens in another step. > > (Here are the details, if you're interested: Each Person random chooses > other Persons to send a message to, and then randomly chooses a message to > send. The pmap over the Persons ends, and all of the messages are > collected into a single hashmap. Then a separate pmap goes through each > Person, applying the messages in the hashmap that are supposed to be sent > to that Person. Thus, although Persons perform their work in some order, > the sending and the receiving of the messages are separated, so that > message sending and receipt occurs as if all messages were sent > simultaneously. In the next timestep, the messages received by a Person > affect the probabilities that various messages will be chosen to send to > another Person.) > > >> A possible clever way around this could be to send the rng state together >> with the message arriving at the agent, to make the agent at least react to >> the state in a similar way. >> > > Interesting idea. I don't think I'll need this, though. > > >> If you have some kind of continous magnitudes in the simulation - like >> pheromones - the simulation would maybe converge to similar results since >> the interaction effects would be reproducible but this is indeed a very >> far-fetched hypothesis. >> > > The simulation converges, but the same parameters can allow convergence to > different outcomes. I usually have to run the simulation many times with > the same parameters so that I can get a
Re: Eval-ing a map expression in Emacs Live doesn't seem to work
On 06/06/2014 17:15, J Irving wrote: Not sure I follow. When you eval in the REPL buffer, you just have to type (foo "name") and hit return. When you do this (and you're in the correct namespace, which you can tell by seeing the namespace in the REPL prompt) it should evaluate correctly. Is that not happening? What buffer are you hitting C-x C-e from? cheers, J Thanks, that's what I needed. I realise I've muddled C-x C-e with a command within Light Table which works with the closing paren of an s-expression. In Emacs you have to be on the next line following the closing paren. Got it now. The road to Emacs/Clojure enlightenment is once more open :) gvim -- 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: Search seqs in seqs
Here's a solution based on your description that behaves like core partition fns, taking liberty to presume your example should've matched the output below. (defn partition-by-seq [sub-seq coll] (letfn [(step [coll] (when-let [coll (seq coll)] (let [[run more] (split-with (partial not= (first sub-seq)) coll) [possible-match more] (split-at (count sub-seq) more)] (if (= possible-match sub-seq) (if (seq run) (cons run (cons possible-match (lazy-seq (step more (cons possible-match (lazy-seq (step more (cons (concat run possible-match) (lazy-seq (step more)))] (or (step coll) ( => (partition-by-seq [:b :c] []) () => (partition-by-seq [:b :c] [:a :d]) ((:a :d)) => (partition-by-seq [:b :c] [:a :b :c :d :a :b :c :d :a :b :c]) ((:a) (:b :c) (:d :a) (:b :c) (:d :a) (:b :c)) On Tuesday, June 3, 2014 4:05:16 AM UTC-5, Ulrich Küttler wrote: > > Hi, > > what is the preferred way to find sub-seqs in a seq? I am trying to convert > > [:a :b :c :d :a :b :c :d :a :b :c] > > into > > ((:a) (:b :c) (:a :d) (:b :c) (:a)) > > using the sub-seq (:b :c) instead of positions. > > partition, partition-by and the like all look at one element at a time. > What I need is a search based on seqs. Are there functions that support > such a search / split? > > Uli > -- 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: Clojure and clojurescript deps in libraries
Hi Nikita,
it does sound like a good advice from a dependency perspective. If you don't do
that clojurescript and all its dependencies leak to projects using your library
and that's definitively problematic. For clojure/clojurescript projects it's
even more important to consider that point.
That said clojure/clojurescript are not regular dependency and by defining a
version you also declare the minimum language features needed by your library.
That's definitively a grey area as both concepts are merged now.
Julien
Le samedi 7 juin 2014 11:08:31 UTC-3, Nikita Beloglazov a écrit :
> Hi
>
> I have a question about best practice for development clojure/clojurescript
> libraries.
> Usually you can see following in project.clj in some library:
>
>
>
>
> :dependencies [[org.clojure/clojure "1.5.1"]
>
> [org.clojure/clojurescript "0.0-2197"]]
>
>
>
> Why not to put clojure and clojurescript deps under :dev profile? All
> clojure and clojurescript projects explicitly specify versions of clojure ans
> clojurescript in their project.clj so I find it reduntant and potentially
> conflicting to inherit them from library. So why put it library project.clj
> in the first place?
>
>
>
> So I would suggest to use :dev profile for this:
>
>
>
> :profiles {:dev {:dependencies [[org.clojure/clojure "1.5.1"]
>
> [org.clojure/clojurescript "0.0-2197"]]}}}
>
>
> Using dev profile means that you have clojure and clojurescript for
> development but when you release library - the library doesn't depend on them
> and users get just code without "infrastructure" deps. I see following pros
> with this approach:
>
> No potential conflicts between library and project depsReduces confusion like
> "ah, library depends on clojure 1.6.0, that means it doesn't work with 1.5.1".
>
> I can't think of cons of this approach.
>
>
> I'd be happy to hear other people opinions on that question.
>
>
> Thanks,
> Nikita
--
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.
Clojure and clojurescript deps in libraries
Hi
I have a question about best practice for development clojure/clojurescript
libraries.
Usually you can see following in project.clj in some library:
:dependencies [[org.clojure/clojure "1.5.1"]
[org.clojure/clojurescript "0.0-2197"]]
Why not to put clojure and clojurescript deps under :dev profile? All
clojure and clojurescript projects explicitly specify versions of clojure
ans clojurescript in their project.clj so I find it reduntant and
potentially conflicting to inherit them from library. So why put it library
project.clj in the first place?
So I would suggest to use :dev profile for this:
:profiles {:dev {:dependencies [[org.clojure/clojure "1.5.1"]
[org.clojure/clojurescript "0.0-2197"]]}}}
Using dev profile means that you have clojure and clojurescript for
development but when you release library - the library doesn't depend on
them and users get just code without "infrastructure" deps. I see following
pros with this approach:
- No potential conflicts between library and project deps
- Reduces confusion like "ah, library depends on clojure 1.6.0, that
means it doesn't work with 1.5.1".
I can't think of cons of this approach.
I'd be happy to hear other people opinions on that question.
Thanks,
Nikita
--
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: bigint and biginteger
Thanks for the historical perspective, puzzler!
In addition to performance considerations, *Clojure Programming* points to
an inconsistency between hash codes for longs and BigIntegers as a
motivation.
Using the example number from that excellent book on Clojure 1.5.1 (on Java
8, FWIW), I can cause this:
#{6948736584 (biginteger 6948736584)}
; => #{6948736584 6948736584}
#{6948736584 (bigint 6948736584)}
; => IllegalArgumentException Duplicate key: 6948736584
clojure.lang.PersistentHashSet.createWithCheck (PersistentHashSet.java:56)
(System/getProperty "java.version")
; => "1.8.0_05"
(clojure-version)
; => "1.5.1"
On Clojure 1.6, thankfully both fail, even in the face of the inconsistency
between .hashCode implementations. If that essentially addresses the 2nd
rationale for introducing a special BigInt class, maybe with both things
being fixed with Java 8 and Clojure 1.6 BigInteger could come back as the
sole arbitrary precision representation of ℤ.
--
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: importing a single function in ns
One small thing - you need a vector around the whole ns piece: (ns foo (:use [com.foo.bar :only [baz quxx]])) But yes, this is fully supported. The recommended way of doing this since 1.4 is to use :require/:refer instead, but the effect is the same: (ns foo (:require [com.foo.bar :refer [baz quxx]])) On 7 June 2014 17:54, Reid McKenzie wrote: > (ns foo > (:use com.foo.bar :only [baz quxx])) > > is totally supported by the ns macro. > > Reid > > On 06/07/2014 12:53 AM, Glen Rubin wrote: > > My namespace currently looks like this: > > > (ns providence.core > (:gen-class) > (:use seesaw.chooser) > (:use seesaw.core) > (:use clojure.java.shell)) > > However, I only use sh from java.shell choose-file from seesaw.chooser and > alert from seesaw.core. > > How do I import these single functions from the namespace? I know that > calling use on it's own you can use the :only keyword, however this doesn't > seem to work in ns. Thanks! > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
