>That's just sloppy work.
I appreciate that you deigned to post assumed problems with my tutorial on the forum and call my work sloppy without even bothering to contact me directly to report the error yourself. If you had done so, I could have told you that the one legitimate problem you mentioned is known, has been reported, and nobody with access has corrected it yet.
>you can see that the numbers produced are 0-9, not 1-10 as the tutorial seems to imply
Yes. This is a known error. However, nobody seems to be updating the FAQ entries, so it remains despite my sending corrections. Since you've written "much more complicated tutorials", you should be well aware that errors happen, even if you are very careful about eliminating them.
Your first complaint is valid (even though everyone already knows about it), but your second complaint is just silly. The fact that the ranges are not evenly distributed is a natural result of fitting a pseudorandom sequence into a smaller range. This is a well known issue (born of shrinking a uniform range so that it is smaller, and thus, no longer uniform) that is typically improved by dropping the numbers through buckets until you find one that you like:
This guarantees that the (supposedly) uniform distribution of the full range is preserved. So it seems like you've gone to great lengths to bash my tutorial when the problem is with pseudorandom numbers and common practice in general. Thanks.
r = rand();
while ( r >= LIMIT );
>I get the same number everytime, which must mean the seed is
>the same everytime I run the code
Yes, it must, mustn't it? Well no, not really. The seed can be different, but if it's not sufficiently different to pull you out of the shrunken range, you'll get the same number for the first call to rand every time. For example, on one of my implementations, in the range [0,9), I can use a seed from 0 all the way to 992 before the first result of rand changes from 0 to 1. You'll see a similar effect by just printing the result of rand and not adjusting the range at all. The first call to rand will give you increasing numbers localized to a small area because the seed is changing only by small amounts in a predictable direction.
You'll notice that the seed is changing, but only if you actually print it, or call rand multiple times, or don't shrink the range and pay attention to the resulting values. This is an issue with the progressive nature of using the system time as a random seed, and is yet another reason why I believe that this common practice (using time() directly in srand) is foolhardy. A far superior method is to take a hash of the system time instead:
If you want to look for errors in something current, try here. I always appreciate bug reports, and with my own site I can quickly fix the errors that are found, unlike the FAQ on this site, where I don't have write access. Anyway, in my defense, that particular tutorial was written in haste, then updated in haste. I ended up rewriting it completely for my website because, looking back at it, nothing could be reused to my satisfaction.
time_t now = time ( 0 );
unsigned char *p = (unsigned char *)&now;
unsigned seed = 0;
for ( i = 0; i < sizeof now; i++ )
seed = seed * ( UCHAR_MAX + 2U ) + p[i];
srand ( time_seed() );