random real number between 0 (inclusive) and 1 (inclusive)

[Piotr Kobzda]

[...]
Anyway, how about reimplementing it as follows:

private static final long maxr = 1L << 53;

private long lastr = nextr();

private long nextr() {
return ((long)next(26) << 27) + next(27) + next(1);
}

This returns 42 twice as often as it returns 0 or maxr.
The mean of the distribution is correct, but the variance is
a wee bit too small: there is too much "central tendency."

That's the property of nextr(). But the "central tendency" is
propagated later into other values through shifting it from lastr. So,
where is no "center".

Is there any point in pursuing this further?

On, if you are satisfied with the results achieved. And maybe it's my
fault, but I'm not.

We've known
since the beginning that there's no practical need for a [0,1]
as opposed to [0,1) distribution, and even if someone wants to
use it for "impractical" reasons a correct solution has already
been posted.

Correct solutions posted already are less efficient than the latest one.

The rest is just intellectual niggling about how
many angels can dance on the least-significant bit, and has
ceased to have much to do with Java programming.

True. But a lot of interesting problems covered by Java are not
strictly Java related, aren't they?

If the question
still interests you as a theoretical study -- there's no harm
and much good in pursuing such interests -- perhaps it would be
better explored in comp.programming, say, or maybe sci.math.

Maybe, but 1) I'm to lazy to start a new discussion (yes, I know, it's a
shame); 2) I know that here are also the people who knows some aspects
of the domains shared by the newsgroups mentioned by you (evidence is
even in this thread!).

Of course, if a luck of the satisfactory answers will cause me waking up
at the middle of the night with a sweat on my brow, I'll consider to
continue it somewhere else. Thanks!


piotr

 

[Piotr Kobzda]

Of course, if a luck of the satisfactory answers will cause me waking up

^ "lack" of course.


piotr

 

[Eric Sosman]

[...]
We've known
since the beginning that there's no practical need for a [0,1]
as opposed to [0,1) distribution, and even if someone wants to
use it for "impractical" reasons a correct solution has already
been posted.

Correct solutions posted already are less efficient than the latest one.

As far as I can tell, the more efficient "solutions"
have all been incorrect. But as I've mentioned (and shown!)
elsethread, I am sometimes rong.

 

[Dr J R Stockton]

Random's nextDouble is specified to be based on this method:

synchronized protected int next(int bits) {
seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
return (int)(seed >>> (48 - bits));
}

seed is a long.

Each call to nextDouble uses a next(26) and a next(27).

You can see a lot of this information in the Random API documentation
at
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Random.html

Interesting.

With a 48-bit seed, there can only be 2^(48-53) of all possible normal
Doubles in [0, 1} returned by that Random; not-perfect.

That suggests another not-perfect implementation for the OP.

Random should return all values in [0, 0.5] with equal probability, and
some others too. So, expressed in Javascript (which I can write <g>?) :

while ((R = Math.random()*2) > 1.0) {}
or do (R = Math.random()*2) ; while (R>1.0)

Disadvantages :
LSB of R mantissa is always zero
Takes average of two loops
If Math.random were perfect, could take infinite loops, improbably
Advantages :
Short
By inspection, will clearly generate R in [0, 1].