2

Math.random() returns a number with 17 digits after the binary point in my console, so the probability of it being exactly 0 is astronomically low. What exactly is the point of that it can technically be 0 but never can be 1, when it is basically never going to return either of those numbers anyway? What led to this? Could someone give me some examples where this property of the Math.random() is relevant?

BoltKey
  • 1,994
  • 1
  • 14
  • 26
  • 3
    Ever seen `Math.floor(Math.random()*N)`? We absolutely don't want to get `N` back there. – Bergi Jun 02 '16 at 16:23
  • `the probability of it being exactly 0 is astronomically low` The point of randomness is to be unpredictable. – idmean Jun 02 '16 at 16:24
  • @idmean the point of randomness is to simulate equal chance of drawing an item `x` from a total pool of `y` i thought? – HC_ Jun 02 '16 at 16:25
  • 1
    "*the probability of it being exactly 0 is astronomically low*" - and so is the probability of any other value in [0,1) – Bergi Jun 02 '16 at 16:26
  • @Bergi I understand that it must never return 1, but why can it return 0? If it couldn't return 0, it wouldn't change anything about that example right? – BoltKey Jun 02 '16 at 16:26
  • @HC_ Actually not. The chance of drawing `x` must be unpredictable. (Since this applies to all `x` you could say that the chance is *equal*.) – idmean Jun 02 '16 at 16:28
  • 1
    @BoltKey: Of course it would change something - the probability of getting `0` would be smaller, and less than the probability to get the numbers 1…N-1. Not by much, that I admit, but given there's only a finite quantities of JavaScript numbers it's still a difference. – Bergi Jun 02 '16 at 16:29
  • @Bergi It would reduce the chance of getting 0 by about 1^15 for n = 100. How is that ever relevant? Don't other aspects of random number generation have far bigger influence? – BoltKey Jun 02 '16 at 16:32
  • 1
    @BoltKey: Well it makes it no longer be properly distributed - and including `0` trivially fixes that, so that's why it's been done. – Bergi Jun 02 '16 at 16:35
  • Don't see how this is specific to JS. I believe most languages do that. – Felix Kling Jun 02 '16 at 16:35
  • Related question: http://stackoverflow.com/q/2143723/218196, http://stackoverflow.com/q/29303769/218196 – Felix Kling Jun 02 '16 at 16:39
  • @idmean that is what i meant, equal chance per item. i may have misworded or misread something. – HC_ Jun 02 '16 at 16:39
  • This is all about the algorithm used which is something like `(m % n) / n` – Alex Kudryashev Jun 02 '16 at 17:02
  • I don't understand why `(0, 1)` is more natural than `[0, 1)`. It seems arbitrary either way. Besides, the `[x, y)` pattern is used elsewhere, like `substring`. Whenever I see a range like this in Java I just assume lower-bound inclusive, upper-bound exclusive, it has been a good rule for me so far. – Pace Jun 02 '16 at 17:06

1 Answers1

1

Typically to produce the random floating-point value a random integer is generated first and then that is scaled to the floating-point range. Because of the binary representation of a floating-point value there are a power-of-two uniformly distributed values between 0 and 1 not including 1.0. If you do include 1.0 then the range is a power of two plus one; and generating a uniform random integer in such a range is much more difficult.

Besides that, returning 1.0 would only cause problems. After you multiply it by a constant you end up with an extremely small chance, but still a chance, of getting exactly that constant. Even after quantising with round-to-nearest you still only get half the chance of occuring compared to any other value (except zero, which also suffers the same penalty).

So it's both easier to do, and more useful.

That said, this is no place to fuss about perfectly uniform distributions. Simply by multiplying a floating-point value, which is inherently restricted to some finite set of values, by a constant and quantising the result, you end up with some results being slightly (immeasurably) more likely than others.

sh1
  • 4,324
  • 17
  • 30