Add initRand() with seed based on time

[metagn]

I assumed there was a reason for this not existing, but now I'm not sure. This proc saves a times import and possible incorrect implementations from Rand initializations that want to use the current time, but don't want to use the global random state. Is there a reason this only exists for randomize?

The randomize with default time seed isn't tested, so I'm assuming this can't be tested either. Will add changelog entry after possible changes are considered

future work

EDIT(timotheecour)

• use monotimes.getMonoTime instead, which has higher resolution.
  Otherwise, low res means lower quality initRand() (esp for multiple threads which would have their numbers more correlated, etc)
• remove dependency on times (a heavy dependency) and use system/timers directly after we address system/timers and std/monotimes are mostly duplicated, should be refactored timotheecour/Nim#572
• std/oids also needs to be updated, ideally calling common refactored code (possibly via some std/private/x if needed) in 2 places:

let t = getTime().toUnix.int32
...
var time = getTime().toUnix.int32

• after this is fixed, we can add tests for initRand (it fails currently because of poor resolution):

  block: # initRand
    for i in 0..<100:
      var r1 = initRand()
      var r2 = initRand()
      doAssert r1.rand(0..high(int)) != r2.rand(0..high(int)), $i

• this should work in VM (at least with --experimental:vmops enabled)
• maybe also randomize could use the upcoming std/sysrand add system random to stdlib by xflywind · Pull Request #16459 · nim-lang/Nim

links

• [feature] random.unpredictableSeed, from pid, threadid, time #8588
• https://dlang.org/library/std/random/unpredictable_seed.html
• unpredictableSeed - D Programming Language Discussion Forum

Process ID, thread ID and system tick

[timotheecour]

how about instead honor experimental:vmops:
if experimental:vmops is passed, it would use it, else would use a fixed seed (ie reproducible builds)

[metagn]

Well you wouldn't use the random module if you cared about predictability. Current compilation isn't pure either, IOEffect procs already exist in VM (though not tagged as such), this would just use a TimeEffect proc. There's no way to check for that experimental, compileOption doesn't work for experimentals, compiles(getTime()) is true under when nimvm even if it doesn't work. Maybe it should be a compile option like --pureVM or --impureVM, but even then the entire random module wouldn't make sense as being pure, other languages have things like RandomEffect (Idris and I believe some Haskell libraries).

[timotheecour]

There's no way to check for that experimental

refs #8644 which is very fixable

[timotheecour]

anyways, this can be fixed in future PR, just leave this comment as un-resolved

[timotheecour]

LGTM, all the other things I mentioned (including future work i added on top) can be done in followup PR's