From: me7@privacy.net
On Fri, 20 May 2005 11:38:46 -0700, in
, Scott Moore
wrote:
>Jim Higgins wrote:
>> On Fri, 20 May 2005 08:47:48 +0000 (UTC), in
>> , Marco van de Voort
>> wrote:
>>
>>
>>>On 2005-05-20, Claudio Cauchi wrote:
>>>
>>>> I solved the problem by eliminating the call to randomize; in the
>>>>procedure generateStudent(var stu:student_record); I still can't
>>>>explain why this happens! It seems that randomize was actually slowing
>>>>down something that wouldn't let the var parameter get updated..Boh
>>>
>>>Nope, since none of these commands are asynchronous. This is not a scripting
>>>language, everything is processed in order. You really should check your own
>>>code for flaws.
>>
>>
>> Of course it's the code, but he can't spot this particular code
>> flaw unless he knows the internal workings of the compiler.
>>
>> The problem is that he placed his call to randomize within the
>> generateStudent procedure which is within for..loop so he's
>> reseeding his RNG each time thru the loop. A fast machine could
>> easily make the required 10 passes thru the loop before the
>> system clock ticks over to the next value. Since randomize seeds
>> the random number generator from the system clock all his random
>> data could be identical, or at most two sets of data since even a
>> slow machine will probably run the code before the clock ticks
>> twice.
>>
>> Removing randomize from the generateStudent procedure and placing
>> it before the for..loop should solve the problem and allow
>> removal of the delay.
>>
>
>Using the system clock to generate random numbers is a mistake for just
>that reason. It isn't random, and can be very unrandom depending on the
>program.
This group is specific to Borland Pascal. What are the
alternatives to users of BP/TP7 given that all development on
BP/TP7 stopped in the 90s?
Neither the BP nor TP7 compilers use the system clock to generate
random numbers. They use the system clock to provide an initial
seed for the software RNG. If the PC hardware provided an
umpteen bit value based on some sort of quantum noise generator,
I suppose the compiler writers would use it, but the hardware
makers didn't provide such a thing in the 90s and they don't
provide such a thing today so seeding from the system clock and
then generating pseudorandom sequences from that starting seed
using a software RNG is the norm for the PC world now and in the
mid-90s when all development on BP/TP7 stopped - making it a moot
point in this group.
There is nothing inherently wrong - in a practical world - with
BP/TP7 using the system clock to *SEED* the RNG. What are the
alternatives given the hardware the compiler and programs run on?
Where else will you get a unique - in a practical sense - seed?
If you have needs not met by this approach, then you're using the
wrong software running on the wrong hardware.
Of course the BP RNG isn't random! No software-only RNG is truly
random. Software-only RNGs are in fact absolutely determinate if
you know the algorithm and the starting seed. For any given seed
the same sequence is produced. If you produce enough values and
stow them into bins, all the bins tend to fill up evenly because
the distribution is apparently random - for practical purposes.
That makes the RNG useful even if not truly random.
>There is a random number generator on my web site:
>www.moorecad.com/standardpascal
>It works even for Borland Pascal.
It wasn't at all apparent where on your site this RNG might be,
but BP/TP already have a built-in RNG that seems to produce an
acceptable distribution of values. I'd need to be convinced the
BP/TP RNG is defective before considering replacing it.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
