[mercury-users] a typeclassful random.m

[Richard A. O'Keefe]

Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
	So are you saying that there should be a function to return a float in [0.0,
	1.0) and another for (0.0, 1.0), or that only the latter is desirable?
	
If the range of possible values is (0.0,1.0), what can go wrong?
    People who were expecting [0.0,1.0) will get a tiny bit of bias
    (one part in 2**53) but every value they get will be a value
    they were prepared to handle.

    For single precision floats I would be uneasy about the level of
    bias.  For double precision floats, not really.  See below.

If the range of possible values is [0.0,1.0), what can go wrong?
    People who were expecting (0.0,1.0) will find log(u) or pow(u,-ve)
    crashing.  A corollary of Murphy's law tells us this will happen
    after delivery, not during testing.

I can see arguments either way, but if only one interface is to be
provided (which is probably simplest for everyone), it should certainly
not be the [0,1) interface.

With respect to bias, a rather more serious issue is just how many of
bits one gets are actually random.  I've lost count of the number of
random number generators I've seen that *said* they returned a double,
but only actually returned 31 random bits (if you were lucky).  With
such an underlying generator, the bias introduced by rejecting 0.0 is
lost in the noise.

--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------