Xref: news2.mv.net comp.lang.c:67399 comp.os.msdos.djgpp:3741
From: Lawrence Kirby <fred AT genesis DOT demon DOT co DOT uk>
Newsgroups: comp.lang.c,comp.os.msdos.djgpp
Subject: Re: Use of random
Date: Sun, 12 May 96 16:53:15 GMT
Organization: none
Lines: 45
Message-ID: <831919995snz@genesis.demon.co.uk>
References: <4mikhp$pa5 AT frodo DOT smartlink DOT net> <Pine DOT SGI DOT 3 DOT 91 DOT 960505200928 DOT 3393B-100000 AT tower DOT york DOT ac DOT uk>
Reply-To: fred AT genesis DOT demon DOT co DOT uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In article <Pine DOT SGI DOT 3 DOT 91 DOT 960505200928 DOT 3393B-100000 AT tower DOT york DOT ac DOT uk>
           slh100 AT york DOT ac DOT uk "Shawn Hargreaves" writes:

>>       To test out my radix_bit_sort function, I've been trying to generate a
>> list of random numbers to sort, and then sort them. The list is rather
>> long, 4000, and I'd like it to be ints, but I can' seem to get it! The
>> program compiles and runs without error, but it gives me #s far larger
>> than integers when I print out some results. I'm using DJGPP v2.
>
>How big is "larger than integers"? Remember that DJGPP is a 32 bit compiler. 
>An integer can hold numbers up to 2^31, and that is pretty big :-)
>
>If you want to limit the number returned by rand() to a specific range, 
>try the mod operator, eg. for an integer from 0 to 99, use rand()%100.

Or read the FAQ to see why this may not be a good idea and get some better
suggestions.

>>    clock();             /* Initialize the clock */
>>    (int *)ticks = clock();
>>    srand(ticks);
>
>I don't think that will do what you were intending it to. If I'm not 
>mistaken, the first time you call clock() it will zero the counter,

No, calling clock() doesn't affect the 'counter' at all, it simply
reads whatever the current value is. There is certainly no guarantee that
clock() returns 0 on the first time it is called. The correct way to use
clock() is to call it twice and take the difference between the values.
In that way it makes no difference where the zero point is.

>and 
>later calls will return elapsed time since the first call. Calling it 
>twice in a row like that will almost always return zero, or some other 
>very small number. A better approach would be to read the system time (by 
>calling time()) and use that as your seed.

Right.

-- 
-----------------------------------------
Lawrence Kirby | fred AT genesis DOT demon DOT co DOT uk
Wilts, England | 70734 DOT 126 AT compuserve DOT com
-----------------------------------------