[mercury-users] a typeclassful random.m

Richard A. O'Keefe ok at cs.otago.ac.nz
Mon Feb 19 14:54:06 AEDT 2007


For some reason I missed the random.c,
but I did look at the tausworthe3.m that was posted not so long ago.

Two points strike me, both of which tend to imply that a good
random generator really ought to be part of the library.

(1) I have often wanted a stream of random integers between some
    lower and upper bounds of MY choice.  A stream of random integers
    between some implementation-defined lower and upper bounds is far
    less use.

    BUT mapping from implementation-defined bounds to application-
    specific bounds in a way that preserves equidistribution is far
    from trivial.  If the implementation range is sufficiently large
    compared with the application range, a quotient and a remainder and
    rejection if the quotient is too high will do.  But how many
    programmers will remember to do that rather than just taking a
    remainder?  And if the implementation range is smaller than the
    application range, getting it right can be very tricky indeed.
    (I note that tausworthe3.m appears to return 0..int.max_int, so
    if I want say -2000000000..2000000000 I am in for a very pleasant
    time, I don't think.)

(2) If you want to generate random bit patterns, something that generates
    the integers 0..2**k-1 for some k is rather convenient.

    But suppose you want to generate random floating point numbers for
    some simulation.  The obvious idiom is
	(convert to floating (next random value))
	/
	(conver to floating (maximum random value) + 1.0)
    giving you a number in the range [0.0,1.0) inclusive.  I have very
    often seen rand()/(double)RAND_MAX in C.
	
    Doug Auclair wrote:
>	I haven't yet reviewed the code, but I also like support predicates
>	to the protocol, particularly rand_float, giving values in the
>	range [0, 1).

    However, there are quite a few applications of random floating point    
    numbers where returning 0.0 would be a devastating bug.  It took me
    ages to get my head around this.  I even patched a copy of the
    Mersenne Twister code to "fix" what I thought was the "bug" of not
    returning 0.0.  Until the day I happened to have one of those uses
    where 0.0 really won't do, and I was Enlightened.  (Oh.  Other people
    really are smarter than me.)

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the users mailing list