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
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 beca
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 pot
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 j.u.c.Thread
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 t
