Random number generators (was: RE: [AD] Allegro 4.2 todos)

["AE" <ae-a@xxxxxxxxxx>]

>>> Humm, already commited a patch that makes the lib and all the
>>> programs/examples to use a private _al_rand()/_al_srand()
>interface. Seems
>>> the best solution to me and also gives pretty good results here.
>>
>> This is blatantly contradictory: how can you make examples use a private
>> function !???? Either it is private and you can't advertise it
>in examples,
>> or it is public and you can. No middle position.
>
>Humm, you're right. But then we're at the starting point again: we can't
>have it private if we want it in the test program (as first case)
>and in the
>other apps (examples, etc.). And if we make it public, how to call it?
>al_rand() comes to mind, but then it sounds like an al_ prefixed
>function in
>an unprefixed library and this is bad IMHO. rand_ex() could fit
>well enough.
>
>Ideas?

I don't like the idea of examples that are not part of the Allegro internals
calling private Allegro internal functions. They're supposed to be examples
of how to use Allegro, and calling a private function is how not to use
Allegro. Following on from the Idea I sugested earlier of having the
internal Allegro random function declared privately and each example using
it's own random function, here are two more variations on the idea.

1. Each example will define a different RNG algorithm. That way, we can show
the users a series of different RNGs.

2. Include the 'alrand' lib with the distribution. This is not part of
Allegro, but we could include it as an example of what an Allegro-addon
should look like and how to use one. That way, each example that uses random
numbers could use alrand.

Of course, the alternative is to just make al_rand() public, but then, there
will be issues trying to re-create the series of random numbers from a given
seed if there are several calls to Allegro functions that use al_rand()
internally. The way to solve this is to have a rand() function that also
takes the seed-value as a paramater. That way, there could be a seed used
internally, and a seed used by the user. Depending on what seed al_rand() is
called with, it will advance the RNG for the given seed. This also has the
advantage that if it's being used in a multi-threaded app where each thread
uses a different seed, then it is possible to easily re-produce the
random-number sequence of a specific thread. Or instead of passing a seed
value, an instance value could be passed (and the instance could be reset
using srand(instance_number,seed) ). That way, two or more instances could
generate a sequence from the same seed, and each instance would internally
keep track of how far in the sequence of numbers for it's seed the instance
has got to. So internally, instance 0 could be used, and all user programs
can use instance 1 and above.


AE.