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

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 beca

Re: Past and future of data.generators

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

Re: Past and future of data.generators

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

Re: Past and future of data.generators

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

Past and future of data.generators

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