À quel point Math.random de JavaScript est-il aléatoire?

Depuis 6 ans, j'ai une page de générateur de nombres aléatoires sur mon site Web. Pendant longtemps, c'était le premier ou le deuxième résultat sur Google pour "générateur de nombres aléatoires" et a été utilisé pour décider des dizaines, voire des centaines de concours et de dessins sur les forums de discussion et les blogs (je le sais car je vois les référents dans mon journaux Web et allez généralement jeter un oeil).

Aujourd'hui, quelqu'un m'a envoyé un courriel pour me dire que ce n'était peut-être pas aussi aléatoire que je le pensais. Elle a essayé de générer de très grands nombres aléatoires (par exemple, entre 1 et 10000000000000000000) et a constaté qu'il s'agissait presque toujours du même nombre de chiffres. En effet, j'ai enveloppé la fonction dans une boucle afin de pouvoir générer des milliers de nombres et bien sûr, pour de très grands nombres, la variation n'était que d'environ 2 ordres de grandeur.

Pourquoi?

Voici la version en boucle, vous pouvez donc l'essayer par vous-même:

http://andrew.hedges.name/experiments/random/randomness.html

Il comprend à la fois une implémentation simple tirée du Mozilla Developer Network et du code de 1997 que j'ai glissé d'une page Web qui n'existe plus ("Central Randomizer 1.3" de Paul Houle). Consultez la source pour voir comment chaque méthode fonctionne.

J'ai lu ici et ailleurs sur Mersenne Twister. Ce qui m'intéresse, c'est pourquoi il n'y aurait pas de plus grandes variations dans les résultats de la fonction Math.random intégrée de JavaScript . Merci!

Donné des nombres entre 1 et 100.

• 9 ont 1 chiffre (1-9)
• 90 ont 2 chiffres (10-99)
• 1 comporte 3 chiffres (100)

Donné des nombres entre 1 et 1000.

• 9 ont 1 chiffre
• 90 ont 2 chiffres
• 900 ont 3 chiffres
• 1 comporte 4 chiffres

etc.

Donc, si vous en sélectionnez au hasard, alors cette grande majorité des nombres sélectionnés aura le même nombre de chiffres, car la grande majorité des valeurs possibles ont le même nombre de chiffres.

Vos résultats sont réellement attendus. Si les nombres aléatoires sont uniformément distribués dans une plage de 1 à 10 ^ n, alors vous vous attendez à ce qu'environ 9/10 des nombres aient n chiffres et 9/100 supplémentaires aient n-1 chiffres.

Il existe différents types d'aléa. Math.random vous donne une distribution uniforme des nombres.

Si vous voulez des ordres de grandeur différents, je suggère d'utiliser une fonction exponentielle pour créer ce qu'on appelle une distribution de loi de puissance :

function random_powerlaw(mini, maxi) {
    return Math.ceil(Math.exp(Math.random()*(Math.log(maxi)-Math.log(mini)))*mini)
}

Cette fonction devrait vous donner à peu près le même nombre de nombres à 1 chiffre que les nombres à 2 chiffres et que les nombres à 3 chiffres.

Il existe également d'autres distributions pour les nombres aléatoires comme la distribution normale (également appelée distribution gaussienne).

Cela me semble parfaitement aléatoire! (Indice: cela dépend du navigateur.)

Personnellement, je pense que ma mise en œuvre serait meilleure, même si je l'ai volée à XKCD , qui devrait TOUJOURS être reconnu:

function random() {
  return 4; // Chosen by a fair dice throw. Guaranteed to be random.
}

L'article suivant explique comment math.random () dans les principaux navigateurs Web est (non) sécurisé: «Suivi temporaire des utilisateurs dans les principaux navigateurs et fuites d'informations et attaques interdomaines» par Amid Klein (2008) . Ce n'est pas plus fort que les fonctions PRNG intégrées typiques de Java ou Windows.

D'autre part, la mise en œuvre de SFMT de la période 2 ^ 19937-1 nécessite 2496 octets de l'état interne maintenu pour chaque séquence PRNG. Certaines personnes peuvent considérer cela comme un coût impardonnable.

Si vous utilisez un nombre comme 10000000000000000000, vous allez au-delà de la précision du type de données utilisé par Javascript. Notez que tous les nombres générés se terminent par "00".

J'ai essayé le générateur de nombres pseudo-aléatoires JS sur Chaos Game .

Mon triangle Sierpiński dit que c'est assez aléatoire:

Eh bien, si vous générez des nombres jusqu'à, disons, 1e6, vous obtiendrez tous les nombres avec une probabilité approximativement égale. Cela signifie également que vous n'avez qu'une chance sur dix d'obtenir un numéro avec un chiffre en moins. Une chance sur cent d'obtenir deux chiffres de moins, etc. Je doute que vous constatiez une grande différence lors de l'utilisation d'un autre RNG, car vous avez une distribution uniforme entre les nombres, pas leur logarithme.

Les nombres non aléatoires uniformément répartis de 1 à N ont la même propriété. Notez que (dans un certain sens) c'est une question de précision. Une distribution uniforme sur 0-99 (sous forme d'entiers) a 90% de ses nombres ayant deux chiffres. Une distribution uniforme sur 0-999999 a 905 de ses numéros à cinq chiffres.

Tout ensemble de nombres (dans certaines conditions pas trop restrictives) a une densité. Quand quelqu'un veut discuter de nombres «aléatoires», la densité de ces nombres doit être spécifiée (comme indiqué ci-dessus). Une densité commune est la densité uniforme. Il y en a d'autres: la densité exponentielle, la densité normale, etc. Il faut choisir quelle densité est pertinente avant de proposer un générateur de nombres aléatoires. En outre, les nombres provenant d'une densité peuvent souvent être facilement transformés en une autre densité par des moyens carieux.