Cela introduira-t-il un biais dans ce qui devrait être des nombres aléatoires?

Supposons un fichier de données avec plus de 80 millions de uns et de zéros, générés aléatoirement.

A partir de ce fichier, nous voulons créer une liste d'entiers décimaux aléatoires.

C'est le plan pour faire cette conversion.

Divisez les 80 millions de chiffres en groupes de 4 chiffres binaires.
Convertissez chaque binaire à 4 chiffres en décimal.
Ignorez toutes les valeurs décimales supérieures à 9.

Cela devrait entraîner une chaîne d'entiers aléatoires de 0 à 9

Voici l'inquiétude. Les 24 chiffres binaires qui comprennent les 6 groupes de 4 chiffres binaires qui correspondent aux valeurs 10 à 15 contiennent 17 uns et seulement 7 zéros. Ce déséquilibre affectera-t-il la distribution des entiers pairs et impairs, ou compromettra-t-il le caractère aléatoire de la dernière chaîne de chiffres décimaux?

Mise à jour: D'après les réponses publiées, il semble que la méthode énumérée ci-dessus soit correcte. Je suis d'accord avec cette conclusion. Cependant, je ne comprends toujours pas pourquoi la suppression de plus de deux fois plus de zéros de la chaîne binaire ne biaise pas le résultat vers moins de nombres impairs. Je cherche des explications.

monte-carlo random-generation randomness

— Joel W.
source

Il existe des méthodes plus efficaces. Par exemple, vous pouvez partitionner la chaîne de bits en groupes de 10, les convertir en leurs représentations à trois chiffres en base 10 et supprimer celles dont les valeurs sont supérieures ou égales à 1000. Cela utiliserait 97,6% des bits plutôt que seulement 62,5% d'entre eux. Vous ne pouvez pas faire mieux que ça. (Vous pouvez utiliser des groupes de 681 et les convertir en chaînes de base 10 à 205 chiffres, utilisant ainsi près de 99,7% des bits.)

— whuber

Réponses:

Comptons et voyons. Par construction du fichier, toutes les chaînes de 4 bits sont également probables. Il existe 16 chaînes de ce type. Les voici:

Votre procédure jette les chaînes 10 à 15. Donc, dans les cas que vous utilisez réellement, vous choisirez 0 à 9, chacun étant également probable, comme vous le souhaitez. Et nous savons que les chiffres décimaux générés sont indépendants les uns des autres car chacun utilise une chaîne distincte de 4 bits et tous les bits sont indépendants. Votre procédure constitue un simple type d' échantillonnage de rejet .

— Kodiologue
source

Je vois clairement cette logique. Pourtant, je crains de rejeter plus de 1 binaire que de 0. Pourquoi ce déséquilibre n'a-t-il aucun impact?

— Joel

@JoelW Je suppose que je ne vois pas votre argument. La distribution finale concerne les chiffres décimaux, pas les bits, donc la distribution des bits n'est pas pertinente.

— Kodiologist

C'est correct, mais cela ne répond que partiellement à la question. Pour répondre à la partie "compromis aléatoire ... de quelque manière que ce soit" de la question, il faut également établir que les chiffres décimaux résultants sont, à une excellente approximation, indépendants . Par souci d'exhaustivité, il vaut la peine de consacrer une phrase d'explication à ce résultat (évident).

— whuber

Joel, je vois d'où tu viens. Il peut y avoir une mauvaise perception ici: vous ne pouvez pas inverser le processus. Si vous souhaitez reconstruire un flux de bits à partir du flux de chiffres décimaux, vous devrez faire quelque chose comme supprimer tous les 8 et 9 et convertir les chiffres restants en triplets binaires. Cela rétablira l'équilibre. En fait, il est facile de voir que ce "voyage aller-retour" équivaut à diviser votre flux d'origine en octets de quatre bits et à éliminer leurs bits les plus significatifs, laissant une belle séquence uniformément répartie de 60 millions de bits.

— whuber

@whuber Assez juste; ajoutée.

— Kodiologist

Il n'y a pas de biais puisque vous simulez simplement certaines valeurs qui sont ignorées et toutes les valeurs, y compris celles qui sont conservées, sont générées avec la même probabilité:

Le code R pour le graphique ci-dessus est

generza=matrix(sample(0:1,4*1e6,rep=TRUE),ncol=4)
uniz=generza[,1]+2*generza[,2]+4*generza[,3]+8*generza[,4]
barplot(hist(uniz[uniz<10],breaks=seq(-0.5,9.5,le=11))$counts,col="steelblue")

— Xi'an
source