14
\$\begingroup\$

Several questions have recently been asking about random. I see a lot of answers in those questions using the date not as a seed but as the random number that is then modulo'ed.

Seen in Java:

System.currentTimeMillis()%N
System.nanoTime()%N

Seen in JavaScript:

new Date%N

Doing so is randomly unfair for two reasons:

  1. the code will often return the same values if run in quick successions, also if the time ticks during two runs, you know you'll get the next value. You may be surprised by the first run, making it random, but not by the next ones.
  2. the the modulo bias is then alive and well.

What are the views of the community on this topic?

\$\endgroup\$
6
  • 8
    \$\begingroup\$ IMHO, this shouldn't be allowed. Random numbers should be generated using pseudorandom libraries in most cases. \$\endgroup\$
    – Gryphon
    Commented Jun 21, 2017 at 10:20
  • \$\begingroup\$ No. Java already has java.util.Random, and Javascript has Math.random(). Relevant. \$\endgroup\$
    – JungHwan Min
    Commented Jun 21, 2017 at 12:41
  • 1
    \$\begingroup\$ I don't think the modulo bias doesn't really apply to this case where there is no upper bound on our numbers. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Jun 21, 2017 at 13:59
  • 1
    \$\begingroup\$ @WheatWizard System.nanoTime() returns a long, there is definitely an upper bound to a long. I don't know how JS represents its numbers in intern, is it a fixed-bits long, double? If it's either, then there is a modulo bias because if it's a long, then see the link I provided or else the lack of precision from certain values make it discontinued, meaning not uniform. \$\endgroup\$
    – Olivier Grégoire
    Commented Jun 21, 2017 at 14:11
  • \$\begingroup\$ Ah, I see I don't use either of these languages and thought that we were talking about using date-time in general. \$\endgroup\$
    – Wheat Wizard Mod
    Commented Jun 21, 2017 at 14:12
  • \$\begingroup\$ @WheatWizard We are discussing using date time in general. But in those two languages, time is always represented at the core by a single number, maening bias one way or another. If you have examples in other languages, they're welcome! :) Plus in Java, System.currentTimeMillis() used to give increments by 15 or 16, so you it returned the same value for 15 actual milliseconds. That was fixed with Java 5 or 6 I don't remember, but that was disturbing at the time ;) \$\endgroup\$
    – Olivier Grégoire
    Commented Jun 21, 2017 at 14:15

4 Answers 4

Reset to default
15
\$\begingroup\$

Yes, for code golf purposes assuming a single random value is required

Selecting a random number is usually not an important part of a golfing challenge, having different results on different runs might be, but usually a random selection once per run is sufficient.

This approach would not work for multiple random values in the same run, but if you have to select one random value per script execution, current seconds/milliseconds should be sufficient.

\$\endgroup\$
4
  • \$\begingroup\$ Would appreciate a qualifying paragraph to make it clear this doesn't apply if you your program might pull 2 random numbers in this manner: it's strongly implied, but I completely missed that point on a first reading (the 'on an individual run' bit in the title just felt like noise, can than be better phrased?). I also think that people should be sensible, and use nano or milli-seconds in this case, so that there is no correlation between repeat runs run by hand (i.e. not in a tight loop). \$\endgroup\$
    – VisualMelon
    Commented Jun 29, 2017 at 7:11
  • 1
    \$\begingroup\$ @VisualMelon I've clarified the language, hope that makes sense and doesn't change the intended meaning for anyone that has so far agreed... \$\endgroup\$
    – Dom Hastings
    Commented Jun 29, 2017 at 11:56
  • 1
    \$\begingroup\$ Yeah, was probably just me being confused, but it's certainly clear now. I would object to using the current date, because it requires more effort than waiting a few seconds before running the program to get a (probably) different result. \$\endgroup\$
    – VisualMelon
    Commented Jun 29, 2017 at 13:28
  • \$\begingroup\$ I will note that even if each execution of your code only uses a single random value, there are some challenges where the scoring relies on running said code numerous times, usually in rapid succession through automated testing. I would consider that implicitly covered (i.e. not "a single random value") but it is a situation that exists and this strategy very much would not be "sufficiently random" despite matching "One random selection per run" by some definitions. \$\endgroup\$
    – Kamil Drakari
    Commented Jul 31, 2017 at 21:43
8
\$\begingroup\$

No, we already have a definition

The community consensus definition of "Random" doesn't include using a time source directly, so unless explicitly allowed, that would fall under a loophole.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ This kind of feels like it's implying that we don't allow amendments on 3-year-old consensuses... \$\endgroup\$
    – ETHproductions
    Commented Jul 31, 2017 at 21:21
  • \$\begingroup\$ @ETHproductions I don't feel an amendment is warranted in this case, so yes I can see how my perspective has skewed the argument slightly. \$\endgroup\$
    – AdmBorkBork
    Commented Aug 1, 2017 at 12:38
3
\$\begingroup\$

First: if the challenge defines random as something other than the default or uniform, new Date%N may be valid or not on a case by case basis. For example, if random means "with non-zero probability" or something similar, new Date should be OK.

Is the current time uniformly random?

I believe that answer to that question, which is the real question here, is no. If, for example, you want to get many truthy or falsey values, new Date%2 will give you something like 1,1,1,1,0,0,0,0,0,1,1,1. That doesn't look "uniform" to me.

\$\endgroup\$
8
  • \$\begingroup\$ Wrong guess; sorry. The trigger was this answer, which I reviewed recently when checking for my past comments. Also, you seem to focus your answer on your guess. Could you please emphasize less on on the guess and make it more generic, taking probably your example in account as an example rather than the base of your point? I like it, but the (wrong) guess takes too much place in my eyes :( Oh, and I just noticed that the answer you mention is yours. Didn't notice, sorry, but I understand the guess at least. \$\endgroup\$
    – Olivier Grégoire
    Commented Jun 21, 2017 at 13:42
  • \$\begingroup\$ @OlivierGrégoire So the real question you're asking is is new Date() uniformly random?? I believe the answer to that is no. I'll edit once you get back to me. Sorry for the assumption, that question was so recent and multiple people on that question used the same tactic. \$\endgroup\$
    – Stephen
    Commented Jun 21, 2017 at 13:48
  • \$\begingroup\$ @OlivierGrégoire edited. \$\endgroup\$
    – Stephen
    Commented Jun 21, 2017 at 13:59
  • 3
    \$\begingroup\$ No: I'm asking if it's random enough given the points I highlighted. Because at the core, it is NOT random. If I use System.currentTimeMillis()%N twice in a row, chances are we get the same value, and if not, we get the next one because the values returned are incremental. PRNGs are defined as random enough, following JungHwan Min's comment. Is the mechanic System.currentTimeMillis()%N random enough? That's the question. Also, new Date%N is not uniformly "random", except if N is a power of 2 (and again... it's not random at the core). \$\endgroup\$
    – Olivier Grégoire
    Commented Jun 21, 2017 at 14:00
  • 3
    \$\begingroup\$ @OlivierGrégoire whether or not it's "random enough" depends on the specs of the question. If the question just says "random", it uses the default definition of random found at codegolf.meta.stackexchange.com/a/1325/65836, which only mentions PRNGs. If you want to change the definition of random, you'd have to go back to that post, I believe. \$\endgroup\$
    – Stephen
    Commented Jun 21, 2017 at 14:04
  • \$\begingroup\$ If you want, I can edit my question for "default random". Regarding the posting in the other question, I think we can discuss it here, then link this discussion there. More clean. \$\endgroup\$
    – Olivier Grégoire
    Commented Jun 21, 2017 at 14:11
  • \$\begingroup\$ What do you mean with new Date%2? Dividing a date by a number doesn't seem like a sensible operation. \$\endgroup\$
    – feersum
    Commented Jul 2, 2017 at 2:24
  • \$\begingroup\$ @feersum the new date is milliseconds since the epoch. If you are looking for a random 1 or 0, getting the parity of the last digit in those milliseconds is what is the topic of the question. \$\endgroup\$
    – Stephen
    Commented Jul 2, 2017 at 11:52
3
\$\begingroup\$

Dates and Miliseconds: no, definitely not

On date objects or any clock measured in miliseconds, I'd say "if used once" (i.e. as a sufficiently random seed to a seeded PRNG), but not for repeated actions. So, no.

Nanos: ...maybe

If grabbing nanos then I'd say it's probably fine. But I'd give it a good, hard squint and check the results.

Individual instructions generally take more than a handful of nanos and while I might be able to write a function that could produce non-random results while using values from System.nanoTime()%N it would be very hard, as if the OS switches the thread to a different core, pauses its execution for another thread momentarily...or anything else in that vane, that pattern would get interrupted and those operations aren't ones that I could predict. And that might be sufficiently random.

Would need investigation.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .