Velocity Reviews > time and srand

# time and srand

Guest
Posts: n/a

 12-20-2007
What kind of problems could arise if
one were to not cast the value of time()
to unsigned int? What are the sections
in the standard that provide the reasoning
of any claims against such a practice?

--

santosh
Guest
Posts: n/a

 12-20-2007

> What kind of problems could arise if
> one were to not cast the value of time()
> to unsigned int? What are the sections
> in the standard that provide the reasoning
> of any claims against such a practice?

The cast is recommended since there is no implicit conversion between
unsigned and time_t. The C standard simply says that time_t is an
arithmetic type. It could be an integer or floating point type.
Therefore an explicit cast is usual when using a time_t value as seed
for srand.

Richard Heathfield
Guest
Posts: n/a

 12-20-2007
santosh said:

>
>> What kind of problems could arise if
>> one were to not cast the value of time()
>> to unsigned int? What are the sections
>> in the standard that provide the reasoning
>> of any claims against such a practice?

>
> The cast is recommended

No, it isn't.

See

or, if that doesn't work and you trust me enough, see
http://tinyurl.com/2ur3c3

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999

Keith Thompson
Guest
Posts: n/a

 12-20-2007
santosh <(E-Mail Removed)> writes:
>> What kind of problems could arise if
>> one were to not cast the value of time()
>> to unsigned int? What are the sections
>> in the standard that provide the reasoning
>> of any claims against such a practice?

>
> The cast is recommended since there is no implicit conversion between
> unsigned and time_t. The C standard simply says that time_t is an
> arithmetic type. It could be an integer or floating point type.
> Therefore an explicit cast is usual when using a time_t value as seed
> for srand.

Yes, there is an implicit conversion from unsigned to time_t, as there
is between any two arithmetic types.

This:
srand(time(NULL));
and this:
srand((unsigned)time(NULL));
are equivalent, assuming you have the required "#include <time.h>".
Since the cast doesn't buy you anything, you might as well leave it
out.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

James Kuyper
Guest
Posts: n/a

 12-20-2007
> What kind of problems could arise if
> one were to not cast the value of time()
> to unsigned int? What are the sections
> in the standard that provide the reasoning
> of any claims against such a practice?

I can't see any plausible problems with not casting the value of time()
to an unsigned int.

I do see possible problems from casting it to unsigned int:

1. If time_t is a signed integer type, the conversion will not be value
preserving for negative values.

2. If time_t is a type with a maximum greater than UINT_MAX, the
conversion will lose the high-order bits.

3. If time_t is a floating point type, the conversion will loose you the
fractional part,

4. If time_t is an imaginary type, the conversion will loose 100% of the
information.

Who suggested to you that conversion to unsigned int was the proper
thing to do, and what reasons did they give?

santosh
Guest
Posts: n/a

 12-20-2007
James Kuyper wrote:

>> What kind of problems could arise if
>> one were to not cast the value of time()
>> to unsigned int? What are the sections
>> in the standard that provide the reasoning
>> of any claims against such a practice?

>
> I can't see any plausible problems with not casting the value of
> time() to an unsigned int.
>
> I do see possible problems from casting it to unsigned int:

<snip>

In light of your, Keith's, and Richard's reply I apologise to the OP for

Keith Thompson
Guest
Posts: n/a

 12-20-2007
James Kuyper <(E-Mail Removed)> writes:
>> What kind of problems could arise if
>> one were to not cast the value of time()
>> to unsigned int? What are the sections
>> in the standard that provide the reasoning
>> of any claims against such a practice?

>
> I can't see any plausible problems with not casting the value of
> time() to an unsigned int.

Agreed.

> I do see possible problems from casting it to unsigned int:
>
> 1. If time_t is a signed integer type, the conversion will not be
> value preserving for negative values.
>
> 2. If time_t is a type with a maximum greater than UINT_MAX, the
> conversion will lose the high-order bits.
>
> 3. If time_t is a floating point type, the conversion will loose you
> the fractional part,
>
> 4. If time_t is an imaginary type, the conversion will loose 100% of
> the information.
>
> Who suggested to you that conversion to unsigned int was the proper
> thing to do, and what reasons did they give?

The context, I think was
srand(time(NULL));
Since srand's argument is of type unsigned int, the conversion will
happen with or without a cast.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

jameskuyper@verizon.net
Guest
Posts: n/a

 12-20-2007
Keith Thompson wrote:
> James Kuyper <(E-Mail Removed)> writes:

....
> > Who suggested to you that conversion to unsigned int was the proper
> > thing to do, and what reasons did they give?

>
> The context, I think was
> srand(time(NULL));
> Since srand's argument is of type unsigned int, the conversion will
> happen with or without a cast.

Depending upon the implementation-specific time representation used
for time_t, that expression might generate only a small number of
different seed values, or it might generate seed values that change
excessively slowly with time. What you typically need in that context
is an expression that generates a different seed value each time you
run the program, and has a roughly equal chance of generating every
permitted seed value.

To minimize dependence upon the representation of time_t, I'd
recommend something like this:

#include <limits.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>

srand(fmod(difftime(0, time(NULL), UINT_MAX+1.0));

That will use different seed values at the rate of 1/second, which
should be good enough for many purposes.

jameskuyper@verizon.net
Guest
Posts: n/a

 12-20-2007
On Dec 20, 2:06 pm, (E-Mail Removed) wrote:
> Keith Thompson wrote:
> > James Kuyper <(E-Mail Removed)> writes:

> ...
> > > Who suggested to you that conversion to unsigned int was the proper
> > > thing to do, and what reasons did they give?

>
> > The context, I think was
> > srand(time(NULL));
> > Since srand's argument is of type unsigned int, the conversion will
> > happen with or without a cast.

>
> Depending upon the implementation-specific time representation used
> for time_t, that expression might generate only a small number of
> different seed values, or it might generate seed values that change
> excessively slowly with time. What you typically need in that context
> is an expression that generates a different seed value each time you
> run the program, and has a roughly equal chance of generating every
> permitted seed value.
>
> To minimize dependence upon the representation of time_t, I'd
> recommend something like this:
>
> #include <limits.h>
> #include <stdlib.h>
> #include <math.h>
> #include <time.h>
>
> srand(fmod(difftime(0, time(NULL), UINT_MAX+1.0));
>
> That will use different seed values at the rate of 1/second, which
> should be good enough for many purposes.

I was thinking too hard; the fmod() is unnecessary, of course.

Richard Heathfield
Guest
Posts: n/a

 12-20-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) said:

<snip>

> To minimize dependence upon the representation of time_t, I'd
> recommend something like this:
>
> #include <limits.h>
> #include <stdlib.h>
> #include <math.h>
> #include <time.h>
>
> srand(fmod(difftime(0, time(NULL), UINT_MAX+1.0));

Lawrence Kirby once proposed the following alternative, which works very
nicely:

#include <limits.h>
#include <stdlib.h>
#include <time.h>

/* Choose and return an initial random seed based on the current time.
Based on code by Lawrence Kirby <(E-Mail Removed)>.
Usage: srand (time_seed ()); */
unsigned
time_seed (void)
{
time_t timeval; /* Current time. */
unsigned char *ptr; /* Type punned pointed into timeval. */
unsigned seed; /* Generated seed. */
size_t i;

timeval = time (NULL);
ptr = (unsigned char *) &timeval;

seed = 0;
for (i = 0; i < sizeof timeval; i++)
seed = seed * (UCHAR_MAX + 2u) + ptr[i];

return seed;

}

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999