Range of Random includes 0.0 or 1.0 ?

What are the ranges of values supplied by the concrete implementations of
Random>>next ?

The comment states that the answer is between 0 and 1, but it doesn't make it
clear whether either endpoint is allowed to be included in the range.

    -- chris

Chris,

> What are the ranges of values supplied by the concrete implementations of
> Random>>next ?
>
> The comment states that the answer is between 0 and 1, but it doesn't make it
> clear whether either endpoint is allowed to be included in the range.

I don't know if it helps but the Blue Book describes the Random class
with ...

"It provides a simple way of obtaining a sequence of random numbers that
will be uniformly distributed over the interval between, but not
including, 0.0 and 1.0."

--
Ian

Use the Reply-To address to contact me (limited validity).
Mail sent to the From address is ignored.

Ian,

> I don't know if it helps but the Blue Book describes the Random class
> with ...
>
> "It provides a simple way of obtaining a sequence of random numbers that
> will be uniformly distributed over the interval between, but not
> including, 0.0 and 1.0."

Hmm, the worst possible choice.  I hope the Dolphin ones don't work that way.

[0.0, 1.0) would be best.
(0.0, 1.0] would be OK, if a little weird.
[0.0, 1.0] is just about bearable, albeit pointlessly hard to use.

But:

(0.0, 1.0) is just nasty...

    -- chris

Chris Uppal wrote:
> What are the ranges of values supplied by the concrete implementations of
> Random>>next ?
>
> The comment states that the answer is between 0 and 1, but it doesn't make it
> clear whether either endpoint is allowed to be included in the range.

The RandomCRT version is [0, 1). The RandomParkMiller appears to be
normally (0,1), but depending on your seed, you can get [0,1]. For
example, "(Random seed: 98784247762) next" returns 0. However, this one
isn't that "random" since all future calls return 1. If you ever get 0,
all future values are going to be 1.


John Brant

"John Brant" <[hidden email]> wrote in message
news:[hidden email]...
You would have to be fairly perverse to use that seed. To get a reasonable
period in the sequence of pseudo-random integers underlying the
RandomParkMiller methods, you have to start with a seed which is an odd
number - hence the default seed is obtained by reading the system clock and
then fixing the low-order bit to be 1. The integers are guaranteed to be
less than the i.v. modulus, and they are divided by modulus to get the final
answer, so the value 1 should be excluded provided the floats have enough
precision. With an odd-valued seed and an odd-valued multiplier, all the
integers produced are odd-valued, so the value zero is also excluded. The
method RandomParkMiller>>lcg, which seems to be the default generator of the
integer sequence in Dolphin X6, has a final line which tests whether the
answer is zero and if so sets it to modulus, so that the final answer is
1.0. With an odd-valued seed this can never happen but, as John says, if an
even seed leads to a zero remainder then all future values will be 1 for
this reason.

Hope this helps

Peter Kenny

John, Peter,

> > The RandomCRT version is [0, 1). The RandomParkMiller appears to be
> > normally (0,1), but depending on your seed, you can get [0,1]. For
> > example, "(Random seed: 98784247762) next" returns 0. However, this one
> > isn't that "random" since all future calls return 1. If you ever get 0,
> > all future values are going to be 1.

I couldn't work out what you were talking about there.  Then light dawned --
the RandomParkMiller implementation has changed a lot between D5 and D6.

In D5 that number (or any multiple of the default "modulus" of 2**31-1) will
just stick at 0.0.  In D6 the picture is a little odder.  For instance:

    (Random seed: (2**31-1) * 333) next.    --> -6.0

Hmmm....

So it seems that the seed should be <= 32 bits, and odd.  And with those
conditions the range is (0.0, 1.0], whereas under D5 it was [0.0, 1.0).  Not
too nice, that.

So, I suppose that the bottom line is:

    Implementations should aim for [0.0, 1.0).

    However client code should neither assume that it is possible
    for it to see either end-point nor that it is impossible to do so.

It was actually the first question that prompted my earlier post (I didn't
express that very well, I admit).  But the second one matters too, and anyway
it's been interesting to peek at the complexities.

Thanks, all.

    -- chris

"Chris Uppal" <[hidden email]> wrote:
>
> So it seems that the seed should be <= 32 bits, and odd.  And with those
> conditions the range is (0.0, 1.0], whereas under D5 it was [0.0, 1.0).
> Not
> too nice, that.
>
Chris

No, I don't think that's right. The D5 version is definitely (0.0,1.0) with
an odd seed - there is no way the remainder can be zero. Similarly with D6 -
apart from the switch to floating point, the only change of logic is the
final test for a zero value, and again the odd seed rules that out. I think
it is (0.0,1.0) for both. I'm not sure that the limitation to 32 bits is
necessary either.

Peter

"Peter Kenny" <[hidden email]> wrote:

> I'm not sure that the limitation to 32 bits is necessary either.
>
Sorry, not thinking straight. It can be over 32 bits provided it is not a
multiple of the modulus.

Peter

Peter,

[me:]
> > So it seems that the seed should be <= 32 bits, and odd.  And with those
> > conditions the range is (0.0, 1.0], whereas under D5 it was [0.0, 1.0).
[...]
> No, I don't think that's right. The D5 version is definitely (0.0,1.0)
> with an odd seed - there is no way the remainder can be zero.

It can be.  The calculation in D5 is:

    seed * multiplier rem: modulus

(since "increment" is zero) so the whole expression will be zero if either the
"seed" or the "multiplier" is zero mod "modulus".  The multiplier is fixed, but
the seed can be chosen to be any multiple of modulus, which causes the whole
sequence to stick on 0.0.

    -- chris

"Chris Uppal" <[hidden email]> wrote:

>  The multiplier is fixed, but
> the seed can be chosen to be any multiple of modulus, which causes the
> whole
> sequence to stick on 0.0.

OK - I had realised that, as my immediately preceding post (belatedly :-))
showed. Further playing with the D6 implementation shows that your condition
> So it seems that the seed should be <= 32 bits, and odd.
should best be formulated as '....the seed should be less than the modulus
and odd.' And with those conditions, both the D5 and D6 versions of
RandomParkMiller are (0.0, 1.0).

I /hope/ that's my final thought. I've just got broadband, and the
excitement of having an 'always on' connection leads me to rush to answer. I
must calm down and learn to think things out first.

Peter