Caves Travel Diving Graphics Mizar Texts Cuisine Lemkov Contact Map RSS Polski
Trybiks' Dive Texts Programming Random()'s Determinism YAC Software
  Back

List

Charsets

Charts

DBExpress

Delphi

HTML

Intraweb

MSTest

PHP

Programming

R

Rhino Mocks

Software

Testing

UI Testing

VB.NET

VCL

WPF

Random()'s Determinism
Delphi (as many other languages / run-times) has a (pseudo)random number generator - based on an initial seed value (the System.RandSeed global variable), it deterministically generates numbers from the range of 0 inclusive to 1 exclusive (the System.Random(): Extended function). It can also generate numbers from any range of positive integer values (the System.Random(Integer): Integer function).

Such determinism is usually described as a negative characteristics of such generators - after all, since it's deterministic (to some level), it's not really random. But as it usually is in programming, we don't need perfect solutions, but solutions good enough...

Moreover, such determinism may be a very useful thing - even though we're getting values that look like random, we know exactly which numbers will appear and in what order... as long as we know the initial seed value. This is very helpful in testing, for instance, when a specific sequence of generated values leads to an error, but other sequences don't. Just set the seed to the first value of the sequence and debug your application as many times as needed.

Each time a new random number is requested, the seed value changes first. Then, based on this new seed, a number is generated from the requested range. This means that if we have a sequence of seed values and randomly generated values based on these seeds:
(s1, v1), (s2, v2), ..., (sn, vn)
we can start our sequence of random values by setting the seed to any of the s values. Then we will get the slice of the sequence starting with the random value in the respective pair (vk if we started from sk).

All this means that if we use random values in an application and for some reason we want to recreate exactly the same sequence of random values as in a previous session, it is usually enough to save the initial seed only, and regenerate the original sequence of random values. Compare this solution with the one in which we have to save all generated values - we need to much less space, for a single value only.

The solution mentioned above is quite ok, provided that the algorithm for generating these values doesn't change. And I'm not talking here about the random number generator itself, but about the calls to the generator's functions - if the order of these change, the random numbers may still be generated in the correct sequence, but the program may be using them in a different order (thus behaving as if was a different sequence).

To show a concrete example: the above solution is used in our YAC Interview Kit applications. This is a on-line survey service where respondents may fill out various kinds of questionnaires. However, it is primarily directed at market research, where often some of the questions and responses are shown in random order (to minimize the influence of the question's or response's position in the list of questions or responses respectively; for instance, responses at the start and end of a list are selected more often than responses in the middle of a list).

So, when a respondent starts a survey, the interviewing program goes through the questionnaire and changes the order of those elements that are defined as random. This doesn't introduce any difficulties in handling such surveys yet. However, a respondent may stop filling out the questionnaire and return to finish it after some time. Obviously, the respondent's session is not kept in memory for that period, but the state of the interview is saved and restored when the respondent returns (so that the interview resumes in the place where it was paused). Moreover, the respondent may decide to go back to a previous question or the order of yet unanswered questions may depend on the order of earlier, already answered, questions.

All in all, we need to keep the order of questions and responses that was initially generated when the respondent started the interview. Instead of keeping all of this information in the DB (the order of all questions and all responses - there may be quite a lot of that), we store the random number generator's seed only (for each respondent independently, obviously). Then, on each session's start, we reorder the questionnaire's elements according to the saved seed. And voila - questions and responses are displayed in exactly the same order as before.

So, we have a random number generator that is good enough for such uses and applications, and on the other hand, we save a lot of DB space and a lot of trouble by saving / restoring the generator's seed only. There are same caveats that go with this (stable algorithm that regenerates values from the seed, for instance), but nevertheless I would consider determinism as a powerful and useful characteristic of such generators.

Top

Comments
Alas!
No comments yet...

Top

Add a comment (fields with an asterisk are required)
Name / nick *
Mail (will remain hidden) *
Your website
Comment (no tags) *
Enter the text displayed below *
 

Top

Tags

Programming


Related pages

TFS - The underlying connection was closed: an unexpected error occurred on a receive.

WCF - The underlying connection was closed: an unexpected error occurred on a receive.

Saving / restoring window placements in .NET

Meaningful identifiers

Public fields vs. properties

A Case for FreeAndNIL

Rounding and precision on the 8087 FPU

Controlling Conditional Defines and Compilation Switches

Registering Extensions

Accessing Protected Members