On 15.12.2008, at 02:24, Mark H. wrote:
>>(lazy-cons X1 (lazy-cons X2 (transform-to-gaussian uniform-
>> rest))
>
> Also much better -- the structs were ugly. Thanks for the nice
> revision!
In fact, this is a good test-case for the interface design for random-
number generators. I
On 14.12.2008, at 18:40, Konrad Hinsen wrote:
> (defn rng-uniform
>"Return an infinite lazy sequence of random numbers"
>[]
>(drop 1 (iterate (fn [_] (rand)) nil)))
>
> (defn transform-to-gaussian
>"Transform a sequence of uniform random number in the interval
> [0, 1)
> int
On Dec 14, 9:40 am, Konrad Hinsen wrote:
> Isn't that the standard Box-Muller transform?
Ah, yes, now I know what to call it ;-) Yes, it's a particular
implementation of the Box-Muller transform that is designed to avoid
trig functions.
http://en.wikipedia.org/wiki/Marsaglia_polar_method
> (d
On Dec 14, 6:09 am, Randall R Schulz wrote:
> On Saturday 13 December 2008 23:19, Mark H. wrote:
>
> > So I'm going to stop pretending like I'm an expert and actually post
> > some Clojure code. Be constructively critical 'cause I'm a n00b in
> > that regard ;-) This is a pseudorandom number ge
On 14.12.2008, at 08:19, Mark H. wrote:
> So I'm going to stop pretending like I'm an expert and actually post
> some Clojure code. Be constructively critical 'cause I'm a n00b in
> that regard ;-) This is a pseudorandom number generator for the
> Gaussian (0,1) distribution.
...
Isn't that t
On Saturday 13 December 2008 23:19, Mark H. wrote:
> So I'm going to stop pretending like I'm an expert and actually post
> some Clojure code. Be constructively critical 'cause I'm a n00b in
> that regard ;-) This is a pseudorandom number generator for the
> Gaussian (0,1) distribution.
>
> ...
So I'm going to stop pretending like I'm an expert and actually post
some Clojure code. Be constructively critical 'cause I'm a n00b in
that regard ;-) This is a pseudorandom number generator for the
Gaussian (0,1) distribution.
(defn next-gaussrand-state [current-
state]
^{:doc "Given the cu
On Dec 5, 2:32 pm, "Mark H." <[EMAIL PROTECTED]> wrote:
> On Dec 4, 12:07 am, "don.aman" <[EMAIL PROTECTED]> wrote:
>
> > Since we're being all high-level, it'd be good for a random function
> > which allows us to specify the range of numbers, since % doesn't
> > promise an even spread of probabil
On Dec 2, 10:42 am, bOR_ <[EMAIL PROTECTED]> wrote:
> I'll compare it later on to the one ruby is using (Mersenne Twister
> Algorithm, which is excellent for monte carlo-like simulations), just
> to get my own bearings.
>
An alternative to MT that is as good, according to RNG expert George
Marsag
On Dec 4, 12:07 am, "don.aman" <[EMAIL PROTECTED]> wrote:
> Since we're being all high-level, it'd be good for a random function
> which allows us to specify the range of numbers, since % doesn't
> promise an even spread of probabilities (especially for large ranges).
Sure it does, as long as you
On Dec 4, 9:07 am, "don.aman" <[EMAIL PROTECTED]> wrote:
> Since we're being all high-level, it'd be good for a random function
> which allows us to specify the range of numbers, since % doesn't
> promise an even spread of probabilities (especially for large ranges).
Not sure if I understand th
On Thu, 4 Dec 2008 00:07:56 -0800 (PST)
"don.aman" <[EMAIL PROTECTED]> wrote:
>
> Since we're being all high-level, it'd be good for a random function
> which allows us to specify the range of numbers, since % doesn't
> promise an even spread of probabilities (especially for large ranges).
If on
Since we're being all high-level, it'd be good for a random function
which allows us to specify the range of numbers, since % doesn't
promise an even spread of probabilities (especially for large ranges).
--~--~-~--~~~---~--~~
You received this message because you
On Dec 3, 9:27 am, Konrad Hinsen <[EMAIL PROTECTED]> wrote:
> I'd provide two interfaces:
>
> 1) Low-level: (rng seed) yielding a pair [random-number, new-seed]
> 2) High-level: (random seed) yielding an infinite (obviously lazy)
> seq of the random numbers obtained starting from the given seed.
On Dec 3, 2008, at 17:45, Mark H. wrote:
> I have the feeling that the "right interface" for a single stream of
> pseudorandom numbers is a seq, rather than a "function" that you
> call.
I'd provide two interfaces:
1) Low-level: (rng seed) yielding a pair [random-number, new-seed]
2) High-level
On Dec 2, 5:42 am, Stuart Halloway <[EMAIL PROTECTED]> wrote:
> Is it big enough to matter? My intuition says "yes". That's worth
> nothing, so I will write some tests when I have some spare time ...
> but secretly I was hoping that this thread would goad someone else
> into writing the tes
For what it is worth, I implemented (for another project) George
Marsaglias XorShift algorithm (as recommended in Java Concurrency in
Practice) in a thread-safe contention free maner, by making the
thread-id part of the source entropy. This way, two threads will
generate different random numbers f
--- On Tue, 12/2/08, Paul Barry wrote:
> Since this is just pure java, shouldn't it be the same on all 1.5
> JVMs? Would it be different on other JVM implementations? Just
> to verify, I checked on my Mac OS X 10.5 and in the Sun JDK
> 1.5 on Windows XP, and it does appear to be the same.
A Su
Since this is just pure java, shouldn't it be the same on all 1.5
JVMs? Would it be different on other JVM implementations? Just to
verify, I checked on my Mac OS X 10.5 and in the Sun JDK 1.5 on
Windows XP, and it does appear to be the same.
On Dec 2, 9:17 am, Stuart Halloway <[EMAIL PROTECTED
2008/12/2 Stuart Halloway <[EMAIL PROTECTED]>:
>
> Cool, that's much better. Can we establish that all (or all important)
> Java 5+ VMs use AtomicLong in next?
While compare-and-swap is a lot better than a mutex, it's still not
free. IIRC a CAS is one (or maybe two) order(s) of magnitude more
exp
Cool, that's much better. Can we establish that all (or all important)
Java 5+ VMs use AtomicLong in next?
> Ah, I didn't see the call to next. The java docs do say that is the
> implementation for that method, but they are lying:
>
>protected int next(int bits) {
>long oldseed, ne
Ah, I didn't see the call to next. The java docs do say that is the
implementation for that method, but they are lying:
protected int next(int bits) {
long oldseed, nextseed;
AtomicLong seed = this.seed;
do {
oldseed = seed.get();
nextseed = (o
Even if you use a per-thread instance, you pay the synchronization
penalty. Because there is no contention, the penalty is lower, but it
is still not zero.
Is it big enough to matter? My intuition says "yes". That's worth
nothing, so I will write some tests when I have some spare time ...
On Tue, Dec 2, 2008 at 3:05 PM, Stuart Halloway
<[EMAIL PROTECTED]> wrote:
>
> nextDouble calls next, which according to Java 5 docs is:
>
> synchronized protected int next(int bits) {
>seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
>return (int)(seed >>> (48 - bits));
>
nextDouble calls next, which according to Java 5 docs is:
synchronized protected int next(int bits) {
seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
return (int)(seed >>> (48 - bits));
}
This is exactly the kind of thing I think we shouldn't have to worry
about in Cl
I wanted to ask what algorithm Java is using for calculating its
random numbers (having a choice of algorithms would be great - some
applications favor one above the other), but I found a website digging
into exactly this question:
http://www.math.utah.edu/~beebe/java/random/README
"I therefore
Looks like the only synchronization is for lazy initialization of the
instance of Random used by the static method:
public final class Math {
private static Random randomNumberGenerator;
private static synchronized void initRNG() {
if (randomNumberGenerator == null)
Clojure's rand delegates to Java's Math.random(), which I am pretty
sure has a synchronized block in it.
One problem with living on top of Java is calling into methods that
have no (conceptual) need to be synchronized. This could hurt
performance in an app carefully written in Clojure to av
28 matches
Mail list logo
