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
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.
I do agree that the name data.generators is not where to look for a
controllable random source. A more specific name for these functions should
be considered.
The java.util.Random has been an issue for me in stress-testing random read
and writes to a huge memory-area by several threads. If I was
One of the challenges with random number generation is that there are quite
a few specialised requirements. I don't believe a generic approach can meet
all needs. I think we actually need a few things:
1. Better implementation for clojure.core/rand etc. I think conditional
usage of
Hi,
I have used http://maths.uncommons.org/ in a few of my projects, so that
could be used in data.random. I have also played with the random.org API in
the past as a source of random numbers.
Thomas
ps. in one of my use cases I also care about the performance of the random
generator as I
clojure.core provides a minimal set of functions for random effects: rand,
rand-int, and rand-nth, currently with no simple ability to base these on a
resettable random number generator or on different RNGs in different
threads. (But see this ticket http://dev.clojure.org/jira/browse/CLJ-1420
