Re: random_number

robin wrote:
James Giles wrote in message ...

robin wrote:

There's nothing "fundamentally flawed" about the method,
as the following proves.  Below are printed the first ten values
below 1.0 (left-hand column) and their products (right-hand column)
the nearest value above 1.0 :-  Only the least-significant 8 bits of
each mantissa are printed.

11111111     00000000
11111110     11111111
11111101     11111110
11111100     11111101
11111011     11111100
11111010     11111011
11111001     11111010
11111000     11111001
11110111     11111000

Most random number generators return values in the interval 0 <= r < 1 that are uniformly spaced in that interval and are equiprobable.

Ideally, yes, but in practice, they are pseudo (note, pseudo)
and aren't perfect.

Both of those last properties
are very desirable.  Your "solution"

It was a suggestion.  Please note the wording:
    "You could try multiplying your random number by
    "NEAREST(1.0, 2.0)
    "and, just for safety, checking that the product is
    "not greater than 1.0.  If it is, replace it with 1.0."

There are many options available to the OP, including
adapting and/or using one of the numerous PNRGs
available in computer science literature and on the internet.

will not return values
on the interval  0 <= r <= 1 that are uniformly spaced.

I am sure that everyone is aware of that.  However,
virtually all are [uniformly spaced].

For example, on IEEE single precision, you get 2^24
values in the interval  0 <= r < 1 and the spacing between
the possible results is 1/2^24.

Do you really think that anyone might notice the one in
some 16,000,000?

In a typical use, the value might never be generated anyway.

Welcome to the school of faith-based programming!

Seriously, though, I've recently been bitten by assumptions that 1-in-10^6 occurences in a RNG-driven simulation are 'impossible'. I've recently been working on a Monte-Carlo simulation of photon diffusion through a porous slab.
In tracking the photons from cell to cell, there are some situations where a photon will propagate through the exact cell corner. However, such situations are so rare that I decided they weren't going to actually arise in simulations, and I didn't bother writing code to handle them.

Of couse, this came back to bite me on the arse. In some of the simulations, I end up firing well over 10^6 photons through the slab -- enough such that the probability of a cell-corner event in a single simulation becomes significant. Hence, my code kept on falling over because I had designated a certain class of events as 'improbable, hence impossible'.