Re: [AD] rand() vs random()

[Peter Wang <tjaden@xxxxxxxxxx>]

On 2003-05-28, Hein Zelle <hein@xxxxxxxxxx> wrote:
> Peter Wang wrote:
> 
> > I'm still against making it public, for more or less the same reasons I
> > gave in September last year.  (Plus another: it should be a crime to
> > knowingly distribute bad RNGs for general use.)
> 
> I'm not sure I remember your reasons from last september,

I'll be a big loud mouth and quote myself:

  1. General principle of post-2.x Allegro: If it can be in an addon, it
  goes in an addon.  RNGs are not even a borderline case.

  2. General principle of my gut: Allegro has too much stuff, so keep out
  even _more_ stuff (unless I'm proposing it, of course).

  3. Pseudo-RNGs are a complex topic.  I won't even try to pretend to have
  a whiff of a clue about the theory, but AFAIK there is no "one size fits
  all" solution.  We could just pick one and incorporate it, but the user
  can do that him/herself, easily, with the side-benefit of picking the
  appropriate generator for the task.

{I have a tiny bit more of an idea now, having looked at the design in
[1] and the process it went through.}

  [this bit from Vincent]
  > The important point is that the standard doesn't mandate the
  > particular implentation of it, so you can't rely on a single
  > seed to yield the same stream of numbers in different libcs.
  > Which rules out nifty things you can do, eg to generate the
  > same level on two different machines playing together just by
  > transmittming the seed, having replay capability just by
  > storing the seed and player/network input, etc).

  4. I don't think the fictional Allegro-RNG would satisfy this either.
  You would need a RNG that guarantees a specific sequence of outputs for
  any particular seed -- for all eternity.  That's very constraining, such
  that even a buggy implementation can't be fixed without possibly
  breaking someone's demo.  If you need an RNG that definitely won't
  change, I think you cannot avoid including it into your own code.

> but I agree
> that distributing a bad RNG with allegro is not good, if it's
> public. I prefer using alrand for the public part: it can be made
> portable and using good algorithms. I guess that leaves the options to
> include alrand in allegro and make it public, or to include a simple
> random generator not visible to the public. I think I prefer the first.

It appears you changed your mind :-)  But alrand appeared in the
meantime.

> > > First, I think as long as allegro only calls rand() and not srand(),
> > > users output shouldn't be affected: as long as you consistently call
> > > the blender functions the same amount of times, your random series
> > > should be reproducable.
> > 
> > But it's unexpected and very fragile.
> 
> It's certainly unexecpected, but I can't think of any cases where it
> would break.

Draw one extra frame (e.g. the user switched away then returned and you
want to restore the screen) and the series is affected.


[1] "SRFI 27: Sources of Random Bits"  http://srfi.schemers.org/srfi-27/

-- 
王浩禎