comp.lang.ada
 help / color / mirror / Atom feed
From: Hugo Pfoertner <hugo.pfoertner@talknet.de>
Subject: Re: basic random number generating methods
Date: Sat, 08 Sep 2001 11:04:12 +0200
Date: 2001-09-08T11:04:12+02:00	[thread overview]
Message-ID: <3B99DF0C.9BD843F8@talknet.de> (raw)
In-Reply-To: 3B99A61A.7E8E@pointecom.net

Lynn Killingbeck wrote:
> 
> sachi wrote:
> >
> > hi,
> > I need to generate thousands of instances of n by n-1 tables for n sometimes
> > >200, the calculations i do on the tables seem to match the theoretical
> > results in some way for large 'n' but for small n say 4 or 6 when i generate
> > say 5 instances of them i get lots of repeated rows or even tables.
> > I am using ADA 95 random number generator which is a LCG, the numbers being
> > generated are then taken modulo of so as to get the desired range. However
> > they aint very random..
> >
> > ..any suggestions for other generators or anything?
> >
> > i havent done any background on this whatsoever but how well distributed are
> > the digits of pi and can we possibly generate the 'kth' digit or whatever
> > using an appropriate function [ok so it may not be very random but well
> > distributed will do]?//
> > //..sachi
> 
> Sounds from other posts like the Ada standard underlying PRNG is pretty
> good. If you are using it, there is yet another popular way to mis-use a
> perfectly good generator to get poor results. That way is to re-seed the
> generator. If you are re-seeding anywhere in your code, other than just
> once at the start and then running your zillions of cases, you can get
> your repeated results. Let's say you use "The System" clock to re-seed,
> and that clock has a resolution of 1 second. If you re-seed back within
> that interval, you will just repeat the previous case. That might
> explain why small sizes repeat, but larger ones don't ('cause the clock
> has ticked over for the larger ones). Make sure you are not re-seeding
> for each case.
> 
> Of course, you can also get into trouble by using too much of the period
> of the generator, but if it is something like 2^49 that's unlikely.
> 
> Do you know such things as the clock resolution on your platform? How
> many bits it has? If there are not a lot of bits, you will also get
> repetitions if you re-seed, but in that case I would expect the repeats
> to be for both big and small.
> 
> Just for your amusement, I'll quote a bit from Plaugher's "The Standard
> C Library" on the topic of <time.h> in chapter 15. You make the call on
> whether the Ada language acts the same, or if Ada refuses to even run on
> a platform with inadequate time resolution and precision. The side-bar
> is called "weasel words": "A vendor could argue that 1 January 1980 is
> always the best available approximation to any time and date. A customer
> can rightly quarrel about the low quality of such an approximation, but
> not whether it satisfies the C Standard." So, if you are seeding with
> "The System" time, and your particular "The System" happens to return a
> constant value (meeting formal standards!) - reach your own conclusion.
> I'll let the Ada Language-Lawyers have their fun with this one.
> 
> Lynn Killingbeck

The Ada95 Performance Requirements for RNG require:
"Two different calls to the time-dependent Reset procedure shall reset
the generator to different states, provided that the calls are separated
in time by at least one second and not more than fifty years."
It is then dependent on the implementation of the "calendar.seconds()"
function, if a reset within one simulation run generates the same
sequence or not. With GHz++ processors, its not so unlikely that exactly
the same time value is returned, even if the "seconds" function has ms
resolution. That might be an issue, when moveing old programs, that have
been designed some years ago, are now executed on high performance
platforms.
Hugo



      parent reply	other threads:[~2001-09-08  9:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Z6Sl7.12146$592.1048488@news2-win.server.ntlworld.com>
2001-09-07 10:30 ` basic random number generating methods HP
     [not found] ` <5ee5b646.0109071057.5d19b56c@posting.google.com>
2001-09-07 21:02   ` Hugo Pfoertner
     [not found] ` <3B99A61A.7E8E@pointecom.net>
2001-09-08  9:04   ` Hugo Pfoertner [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox