[m-rev.] time additions (was Re: for review: Add random.init/3)
novalazy at gmail.com
Thu May 26 13:05:31 AEST 2016
On Thu, 26 May 2016 12:15:52 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> On Thu, 26 May 2016, Paul Bone wrote:
> > On Thu, May 26, 2016 at 11:25:16AM +1000, Peter Wang wrote:
> >> On Wed, 25 May 2016 16:28:32 +1000, Peter Wang <novalazy at gmail.com> wrote:
> >> A common way to seed the PRNG in C is
> >> srand(time(0));
> >> The time in seconds-since-the-Unix-epoch is useful for many other
> >> purposes, in addition to seeding any PRNG implementation.
> >> I would like to see an easy way to get an integer (simple)
> >> representation of Unix time, as well as a way to convert between an
> >> integer representation and the time_t values.
> >> The main problem is probably that a signed 32-bit int cannot represent
> >> Unix times past some time in 2038. Apart from 32-bit machines, this
> >> problem also affects C# and Java backends.
> >> difftime/2 returns a float. You can get the current unix time as a
> >> float with
> >> time(Now, !IO),
> >> Secs = difftime(Now, unix_epoch)
> >> where `unix_epoch' returns a time_t.
> >> Using floats is not very satisfying but in most cases they will be
> >> double precision, and capable of representing any reasonable time
> >> value precisely.
> I think we should define Mercury's float type to always be a double
> precision type and just do away with the spf grade component entirely.
> That would deal with the "most cases" issue above.
Fine by me.
> > Eww,
> > My reaction to the use of floats for this kind of thing is rater visceral.
I understand, but doubles can represent values to 2^53 precisely.
% date -d @$(( 2**53 ))
Mon Nov 12 18:36:32 AEDT 285428751
That ought to be enough for anybody...
> > I agree that it may be useful to expose time in seconds since the epoch for
> > other reasons. And as an aside, gettimeofday() could be useful if portable
> > too.
> 4. Seed the PRNG using something other than time, for example:
> :- pred generate_random_int(int::out, io::di, io::uo) is det.
> and generate the int using /dev/random (on Unix) or CryptGenRandom (on
> Windows), or whatever the appropriate OS / platform specific source of
> randomness is. (Most OSs -- and certainly the ones that Mercury
> actually runs on -- will provide something along those lines.)
That would be useful, too.
More information about the reviews