[mercury-users] Converting time_t to int using common library?

[Mark Brown]

On 15-Feb-2007, Ralph Becket <rafe at csse.unimelb.edu.au> wrote:
> doug.auclair at logicaltypes.com, Wednesday, 14 February 2007:
> > Great!  Thank you for the RNG.  Is it better than the "Mother of all
> > RNG" supplied as module rnd in qcheck?
> 
> I have no idea,

The answer to this question is no.  Likewise, the Mersenne twister is not
uniformly better than Tausworthe.

Check out <http://random.mat.sbg.ac.at/> for a whole lot of good stuff
on RNGs.  In particular these quotes:

	All random number generators have their weak points.

	Every RNG has its deficiencies. No RNG is appropriate for all tasks.

This is why I've been objecting all along to the idea of putting "the best"
RNG in the standard library, or of giving our endorsement to any particular
implementation, or indeed of implying that there even exists such a thing
as the best RNG.

There are two ways that I can think of to get users to understand that we
are not endorsing any particular RNG.  First, provide a well known and
obviously bad RNG (the better-the-devil-you-know approach).  We currently
provide Knuth's "quick and dirty" generator, and anyone who bothers to read
documentation will observe that we don't endorse it.  Second, and preferable,
is what Julien said: provide one interface to a variety of different RNGs,
each with a description of its strengths and weaknesses.

In either case, the interface should encourage the proper use of the given
RNG (the comments in random.m illustrate what I mean by "proper").  And
there's the rub: different RNGs will have a different idea of what is proper,
and defining one interface that mitigates all of the various pitfalls is a
task that is beyond my competence at the present time.  I suspect there will
be plenty more "other people are smarter than me" moments for anyone who
undertakes this task with any amount of diligence.

> but this link
> www.cs.dartmouth.edu/~akapadia/project2/node27.html

"Project 2"?  Are you citing someone's coursework?

> tests some RNGs and concludes that "The Tausworthe RNG... is the best
> RNG amongst the RNGs that we tested."

Bzzzt!  No A+ for you.  Even their own tables point out that Tausworthe
is worse than MT on at least two empirical tests.

Moreover, it is worth pointing out that the above analysis only tests
individual streams of random numbers.  In no way do they attempt to test
whether there is any correlation between two supposedly independent
streams.  If we are to provide an RNG that can be seeded multiple times
(and not just one that gets all numbers from the IO state), then we need
better assurances than from the above.

On 15-Feb-2007, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> Julian Fondren wrote:
> > On 2/13/07, Peter Schachte <schachte at csse.unimelb.edu.au> wrote:
> >> One problem with this is that if you call it twice in rapid
> >> succession, it
> >> will
> >> probably give you the same random supply.  It would probably be better
> >> for
> >> subsequent calls to this to us some function (e.g., xor) of the time
> >> and the
> >> previously generated seed.
>
> > However, xor doesn't work very well for this: given a cached seed S, the
> > second
> > of two functionally simultaneous calls to random.init will return S.  I
> > think
> > + would do better.
>
> + is good, too, although it throws away 1 bit of entropy on the carry out.
>
> xor would be OK, too, as long as the creation of a fresh var supply also runs
> the random number generator once, so that the new seed is an unpredictable
> function of the previous seed and the date/time.

Pardon me, but this kind of ad hoc reasoning should NEVER be used when
designing RNGs.  Too many mistakes have been made along these lines in
the past (including by the ghc people, IIRC).  There do exist "splitting"
RNGs which are able to produce independent streams [1].

Cheers,
Mark.

[1] P. L'Ecuyer, R. Simard, E. J. Chen, and W. D. Kelton, ``An Object-
Oriented Random-Number Package with Many Long Streams and Substreams'',
Operations Research, 50, 6 (2002), 1073--1075

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