Jouons à Pile ou Face

Bonjour,
Je cite une vérification faite il y a de nombreuses années. Bien qu'il ne soit pas très présentable, je garde le même document. Mais chacun peut faire sa propre simulation, il obtiendra naturellement quelque chose de comparable.
Le principe est d'étudier les listes de piles, resp. faces, à cette époque on raisonnait plutôt dans un contexte de casino.



On peut observer que la boule ne se trompe pas trop souvent et qu'elle respecte, tant bien que mal, les occurrences qui lui ont été assignées par la loi.

Oui, c'est un petit peu (et même pas mal) du réchauffé, n'est-ce pas ?
https://dlz9.forumactif.com/t1921p25-gaussienne-non-centree#22724

Toujours avec pile ou face.
Le principe est simple on tire un grand nombre de fois à pile ou face. Si c'est pile on note 0, si c'est face on note 1. Donc on obtient une longue suite de '0' et de '1'. On remarquera que l'on distingue "série" de "suite", puisque les résultats sont ordonnés. On dit c'est une série de mots de 7 chiffres 0 ou 1, soit une suite de nombre binaires qui valent de 0 à 127 en décimal.
On comptabilise les nombres d'occurrence de chacun de ces 128 nombres :

Code:

Nombres crés par Pile ou fce calculé avec %2
Nombre = 128  Moyenne = 781.25  emq=16.72  ep=11.14
Médiane = 784.50 Min = 737.00  Max 821.00
   Rapport EMQ/EMA = 1.25  théorique 1.25
Classe 1  nb=   0  0.00%    théorique 0.35% |
Classe 2  nb=   3  2.34%    théorique    2% |HHH
Classe 3  nb=   8  6.25%    théorique    7% |HHHHHHH
Classe 4  nb=  22  17.19%   théorique   16% |HHHHHHHHHHHHHHHHHH
Classe 5  nb=  31  24.22%   théorique   25% |HHHHHHHHHHHHHHHHHHHHHHHHH
Classe 6  nb=  34  26.56%   théorique   25% |HHHHHHHHHHHHHHHHHHHHHHHHHHH
Classe 7  nb=  18  14.06%   théorique   16% |HHHHHHHHHHHHHHH
Classe 8  nb=   7  5.47%    théorique    7% |HHHHHH
Classe 9  nb=   5  3.91%    théorique    2% |HHHH
Classe 10 nb=   0  0.00%    théorique 0.35% |

On observe que la répartitions est conforme à la répartition normale, c'est donc que la pièce ne s'est pas trompée de sens trop souvent.

La première simulation (premier message) est une bonne vérification de la loi des grands nombres où la moyenne tend vers la probabilité, la présente simulation est une bonne vérification de la répartition normale d'une expérience aléatoire.
Il est possible que certains lecteurs se posent la question "quelle loi de probabilité suit la pièce ?" La répons est simple : la loi du hasard.

Oh, cet simulation, je l'ai faite il y a une vingtaine d'années et apparemment ça n'a pas convaincu. Je l'ai mise plusieurs fois, c'est au moins la cinquième.

Les probabilités faisant partie des mathématiques, on y démontre des choses. Et une fois qu'on a démontré quelque chose, on peut l'illustrer par une simulation.

Par exemple, vous tirez 100 000 fois un entier uniformément entre 0 et 127 (dans votre protocole, les 128 entiers sont bien équiprobables). C'est alors un résultat facile à démontrer que, pour tout entier a entre 0 et 127, la variable aléatoire N_a "nombre d'occurrences de l'entier a" suit la loi binomiale de paramètres 100 000 et 1/128, d'espérance  100 000 / 128 = 781.25 et d'écart-type √(100 000 * (1/128) * (127/128)) = 27.84...
Vous devriez trouver un écart-type voisin dans votre simulation ... or vous trouvez 16.72, ce qui est vraiment très loin de 27.84.
Il y a donc quelque chose qui cloche, la dispersion de vos 128 nombres n'est pas ce qu'elle devrait être., ce qui se manifeste aussi avec un minimum trop élevé et un maximum trop bas.
Pour en avoir le coeur net, j'ai fait moi-même la simulation et elle confirme bien entendu le calcul de l'écart-type.

Vous êtes bien sûr du protocole mis en oeuvre ? Vous tirez sept fois à pile (0) ou face (1), cela vous donne l'écriture binaire d'un entier entre 0 et 127. Vous répétez ça 100 000 fois et vous prenez les 128 scores des 128 entiers.
Si c'est bien le protocole, je soupçonne un bug dans votre simulation.

Pouvez-vous refaire votre simulation pour vérifier ? Et si la différence sur la dispersion persiste, pouvez vous publier votre code ?
(Je publierai bien sûr le mien si vous le souhaitez).
Merci.

Il est possible que certains lecteurs se posent la question "quelle loi de probabilité suit la pièce ?" La répons est simple : la loi du hasard.

La réponse est encore plus simple : la pièce est simulée par le générateur de nombres pseudo aléatoires de votre implémentation de C++ ; ce n'est pas la loi du hasard. J'ai cru comprendre que votre système est ancien, le générateur de nombres pseudo-aléatoires n'est peut-être pas de très bonne qualité. Est-ce que cela peut expliquer le problème avec votre simulation vu que, si j'ai bien compris votre protocole, vous faites tout de même 700 000 tirages ? Peut-être, je ne sais pas.

Bonsoir, votre message n'est pas sans intérêt.
Il se trouve que j'ai lu quelque part que quand on utilise mod(2) on obtient des résultats étonnants. Alors j'ai essayé, le principe de base de l'esprit scientifique, et j'ai fait aussi une simulation en utilisant l'opération mod(100) avec naturellement la comparaison à 50. Là vous avez parfaitement raison, l'écart-type est ce que vous avez calculé de votre côté.
Ci-dessous le résultat :

Code:

Nombres crés par Pile ou fce calculé avec %100
Nombre = 128  Moyenne = 781.25  emq=27.55  ep=18.37
Médiane = 797.50 Min = 710.00  Max 844.00
    Rapport EMQ/EMA = 1.24  théorique 1.25
Classe 1  nb=   0  0.00%      théorique 0.35%    |
Classe 2  nb=   4  3.12%      théorique    2%    |HHHH
Classe 3  nb=   8  6.25%      théorique    7%    |HHHHHHH
Classe 4  nb=  19  14.84%     théorique   16%    |HHHHHHHHHHHHHHH
Classe 5  nb=  32  25.00%     théorique   25%    |HHHHHHHHHHHHHHHHHHHHHHHHH
Classe 6  nb=  31  24.22%     théorique   25%    |HHHHHHHHHHHHHHHHHHHHHHHHH
Classe 7  nb=  21  16.41%     théorique   16%    |HHHHHHHHHHHHHHHHH
Classe 8  nb=  12  9.38%      théorique    7%    |HHHHHHHHHH
Classe 9  nb=   1  0.78%      théorique    2%    |H
Classe 10 nb=   0  0.00%      théorique 0.35%    |
    

Cette différence pourrait rentrer dans le cadre de problèmes avec les générateurs, ce qui a déjà été étudié. Mais, en ce qui me concerne, les générateurs n'ont jamais été une preuve de quoi que ce soit, la seule chose importante, c'est la théorie des probabilités, mathématiques ou pas, générateur ou pas.

Petite explication complémentaire que j'ai peut-être déjà donnée. Dans mon cours il est écrit : cette expérience a été faite bien des fois [...]avec les exemple de tir sur cible et de jeu à pile ou face. On a déjà échangé vigoureusement à propos du tir sur cible, je me posais la question de savoir comment on avait fait avec pile ou face (en 1960 l'informatique était quasi-inexistante) alors j'ai trouvé cette méthode et assurément, elle vaut toutes les vérifications de la répartition normale des résultats d'une expérience aléatoire de même support et même protocole. Même si cela choque vos fondements mathématiques.

Vous voyez, la théorie des probabilités des matheux (celle de tout le monde) a tout de même du bon ! Vous avez constaté que ce que j'écris mérite tout de même d'être pris au sérieux. Je vous félicite d'avoir fait l'essai et de reconnaître que j'avais raison.

Pourquoi devrais-je être choqué dans ce cas par une répartition sensiblement normale ? Vous ne pouvez pas vous empêcher de dénigrer, même après avoir constaté le sérieux de mes arguments mathématiques ?

Moi a écrit:la variable aléatoire Na "nombre d'occurrences de l'entier a" suit la loi binomiale de paramètres 100 000 et 1/128, d'espérance  100 000 / 128 = 781.25 et d'écart-type √(100 000 * (1/128) * (127/128)) = 27.84...

Vous pensez que je ne sais pas qu'une telle loi binomiale (la somme de 100 000 variables de Bernoulli) est proche d'une loi normale ?
Par contre, votre formulation sur "la répartition normale des résultats d'une expérience aléatoire de même support et même protocole" n'est pas correcte.  Ce qui est correct (mais un peu vague), c'est que la somme d'un nombre suffisant de résultats d'une expérience aléatoire de même support et même protocole a une répartition à peu près normale. C'est comme cela que Paul Lévy, par exemple, explique la répartition normale des erreurs accidentelles. Je veux bien vous expliquer plus, mais d'une part il est tard et d'autre part, je sais bien que vous allez encore une fois refuser tout argument scientifique et prétendre que je ne connais rien....

Bonsoir Humx3,
J'ai appris un nouveau terme mathématique : "à peu près". Il est vrai que vous en avez employé un autre assez folklorique en mathématique : "ressemble" mais j'ai eu la correction de ne pas relever.
Bonne soirée.

Bonjour Dlzlogic,
J'ai bien spécifié que la formulation était vague, donc non mathématique. C'était intentionnellement, pour rester à votre niveau. Si vous préférez, je peux formuler une nouvelle fois le TCL dans le cas particulier de la situation que vous simulez. Mais comme vous ne comprenez pas "variable aléatoire" ou "converge en loi", et de manière générale les mathématiques y compris la théorie des probabilités, c'est comme "pisser dans un violon", comme on dit vulgairement.

Un petit dessin pour préciser le "à peu près normale". Sur ce dessin je fais figurer en bleu la distribution binomiale de paramètres 100000 et 1/128, et en rouge la distribution normale de même espérance et de même écart-type. On voit que les deux courbes coîncident "à peu près", mais pas "tout à fait".

Bonjour Humx3,

h a écrit:J'ai bien spécifié que la formulation était vague, donc non mathématique. C'était intentionnellement, pour rester à votre niveau. Si vous préférez, je peux formuler une nouvelle fois le TCL dans le cas particulier de la situation que vous simulez. Mais comme vous ne comprenez pas "variable aléatoire" ou "converge en loi", et de manière générale les mathématiques y compris la théorie des probabilités,

Vous êtes d'une grossièreté et d'une suffisance inimaginable.
Je veux bien que vous formuliez le TCL dans le cas général.
Je veux bien que vous formuliez le TCL "dans le cas particulier de la situation que je simule".
Je veux bien que explicitiez l'expression "variable aléatoire" : fonction ou valeur ou les deux suivant les cas.
J'ai très bien compris VOTRE théorie des probabilités, ce que j'aimerais, c'est un exemple que l'on pourrait détailler et justifier.

Dans votre graphique, très nettement il s'agit d'un écart systématique. C'est tout de même très bizarre qu'on puisse avoir un écart systématique entre deux formules théoriques, tout étant égal par ailleurs. Sachant que la distribution normale résulte d'une formule bien précise et que personne ne remet en cause, c'est manifestement votre répartition binomiale qui est approchée. Il me semble assez compréhensible que si la répartition binomiale était exacte, on ne s'embêterait pas avec la répartition normale, dont la formule est démontrée. Ca c'est un détail sans grande importance.

Par contre, j'ai un peu de mal à comprendre la différence de résultats entre mes deux simulations. Je suppose que ce n'est pas vous qui aurez une idée ou même une piste de recherche.

Je vais commencer par là :

J'ai très bien compris VOTRE théorie des probabilités, ce que j'aimerais, c'est un exemple que l'on pourrait détailler et justifier.

Remarque préliminaire : c'est la théorie des probabilités de tout le monde, sauf vous.
"Un exemple que l'on pourrait détailler et justifier " vient d'être donné dans le fil : quelqu'un fait une simulation qui consiste à tirer 100000 fois des suites de 7 bits 0 ou 1 et à noter à chaque fois l'entier entre 0 et 127 dont c'est l'écriture binaire. Il regarde ensuite la distribution des nombres d'occurrences de ces 128 entier. Il trouve une moyenne de 781.25 (ça ne peut pas être autrement !) et un écart-type de 16.72. Une autre personne, qui connaît la théorie des probabilités de tout le monde, comprend que le nombre d'occurrences est la somme de 100000 variables de Bernoulli indépendantes de probabilité de succès p = 1/128, et donc c'est une loi binomiale d'espérance 100000 * p = 781.25 et de variance 100000 * p * (1-p), c.-à-d. d'écart-type 27.84. Au vu de l'énorme différence avec l'écart-type trouvé par la personne qui a fait cette simulation, elle conclut que cette simulation a un bug. Et bingo, la simulation refaite d'une manière plus sûre donne un écart-type de 27.55.
Si la personne qui a fait la simulation comprenait mieux la théorie des probabilités de tout le monde, elle aurait pu faire elle-même le petit calcul élémentaire et s'apercevoir du bug avant qu'on lui fasse remarquer.

Ce que vous ne savez pas ou que vous n'avez pas lu ou pas compris, c'est que cette simulation était dans machine, avec justement les deux utilisations du générateur. J'avais lu cette information concernant la sortie de 0 ou 1 et je voulais vérifier et essayer de comprendre. J'ai vérifié, mais je n'ai pas compris et apparemment ce n'est pas vous qui allez m'aider.
Quand je demande un exemple, c'est que je crois réellement que à part des petits couplets comme vous venez de le faire, cette théorie n'a pas vraiment d'utilisation, pour la raison très simple est qu'il y manque une notion fondamentale : le hasard.
En fait presque chacun de vos messages me confirme que vous n'avez que des notions très théoriques et abstraites des probabilités et que malheureusement pour les étudiants, ces notions sont parfaitement inutiles.

Petit exemple très simple de votre méconnaissance totale des probabilités, vous vous intéressez à la valeur de l'écart-type, mais pas à la répartition. Si vous n'avez pas la formule vous donnant cette valeur d'écart-type, vous ne connaissez aucun moyen de contrôle d'un résultat, alors que justement c'est l'une des finalités principale de cette théorie.

Toujours le même baratin, et quand vous vous risquez à quelque chose de concret comme votre dernière simulation, c'est buggué et vous ne vous en apercevez pas. Vous pensez vraiment être crédible ?

Venons en à votre paragraphe insensé sur binomial/normal. Ça commence de façon péremptoire :

Dlzlogic a écrit:Dans votre graphique, très nettement il s'agit d'un écart systématique.

Vous dites ça, je suppose, parce que vous voyez le bleu à gauche du rouge. Manque de bol sur d'autres plages de valeurs le bleu est à droite du rouge.

Pour l'erreur systématique, vous repasserez !

vous ne connaissez aucun moyen de contrôle d'un résultat, alors que justement c'est l'une des finalités principale de cette théorie.

Décidément, vous avez la mémoire très courte. Vous avez déjà oublié que je viens de vérifier que le résultat de votre simulation n'était pas vraisemblable ?

Manifestement vous ignorez que l'écart-type n'est qu'une unité de mesure, on en choisi éventuellement d'autres, suivant les besoins, l'écart probable ou l'écart moyen arithmétique.
Vous parlez de vérification, ce qu'il avait à vérifier et c'était le but de mon module, c'est le problème du calcul de 0 ou 1 avec la fonction rand. Mais ce problème vous passe complètement au-dessus de la tête puisque votre logiciel a résolu le problème.
Ce qui vous passe aussi complètement au-dessus de la tête, c'est que toute expérience menée dans les mêmes conditions produit une moyenne et la répartition des écarts à cette moyenne est celle de la loi normale : second théorème de Berboulli.
Le premier théorème de Berboulli, connu sous le nom de loi des grands est vérifié par la simulation donnée dans mon premier message.
La seconde simulation vérifie le second théorème de Bernoulli, simplement avec pile ou face.

Essayons de donner à lire des choses plus intéressantes que du baratin creux.

1°) Je reviens sur la comparaison binomial /normal. Elle est souvent faite avec du binomial de paramètre p = 1/2. Ici on travaille avec p = 1/128. On constate dans ce cas que la distribution binomiale n'est pas symétrique. Pour mieux apprécier, je prends le paramètre n=1000 (donc 1000 tirages d'entiers entre 0 et 127, distribution du nombre d'occurrences d'un entier donné). La binomiale est alors plus loin de la normale qu'avec n=100000, bien sûr. Voici la comparaison sur la plage 0-16 occurrences :
La distribution binomiale est figurée par une ligne brisée, vu qu'il s'agit d'une loi de probabilité discrète.
On constate que par rapport à la distribution normale de même espérance et de même écart-type, la binomiale tire à gauche dans la partie centrale et à droite dans les queues.

2°) D'où vient le bug dans la simulation de Dlzlogic, que j'ai détecté par un petit calcul de probabilités élémentaire ?
Une piste que j'évoquais est la mauvaise qualité du générateur de nombres pseudo-aléatoires. Je cite :

There are no guarantees as to the quality of the random sequence produced. In the past, some implementations of rand() have had serious shortcomings in the randomness, distribution and period of the sequence produced (in one well-known example, the low-order bit simply alternated between 1 and 0 between calls). rand() is not recommended for serious random-number generation needs, like cryptography.

"In the past", ça concerne l'installation de Dlzlogic qui est assez ancienne d'après ce que j'ai compris.
Mais il faudrait commencer par vérifier l'écriture du code de Dlzlogic pour s'assurer qu'il n'y a pas de problème à ce niveau. Pour cela, il faudrait que Dlzlogic fournisse son code ...

Il ne faut pas mélanger les choses.
J'ai écrit ce code il y a quelque temps pour essayer de cerner ce problème de 0-1.
J'ai constaté que il y avait bien une différence suivant que je faisais mod(2) ou mod(100). Je n'en ai pas essayé d'autres, mais, en fait, à part le constat, je n'étais pas plus avancé. D'ailleurs l'article qui parlait de ce point ne donnait pas d'autre solution.

J'ai eu envie d'ouvrir un fil que j'ai nommé "jouons à pile ou face". Il n'y avait rien de nouveau, mais comme personne ne voulait faire la vérification de la distribution normale, second théorème de Bernoulli, c'était la bonne occasion de refaire cette simulation. Je ne me souvenais plus que j'avais déjà le module dans ma machine, il m'a suffit de recopier le résultat. Il se trouve que c'était celui avec mod(2) que j'avais exécuté en dernier.

Oui, il y a un problème au niveau du générateur, ce n'est pas nouveau et c'était le but de ce module. Cela n'a bien sûr rien à voir avec l'ancienneté de mon compilateur.

Si le hasard avait fait que la dernière version que j'ai regardée il y a quelques mois avais été avec mod(100) il aurait fallu qu'il y ait un autre sujet pour me critiquer. En tout cas, bravo, vous avez trouvé de quoi fait une diversion par rapport au sujet principal : vérifier l'exacritude du théorème de Bernoulli concerné avec simplement le jeu de pile ou face.

La comparaison entre la "loi binomiale" et le "théorème loi normale" est sans objet. En maths c'est pas "comme on veut", il n'y a aucun choix humain dans cette opération, la seule variable est le hasard.

J'observe que vous aimez bien écrire que les choses sont "sans objet" quand vous ne les comprenez pas.
Je comprends que, comme d'habitude maintenant, vous n'allez pas partager votre code.

comme personne ne voulait faire la vérification de la distribution normale, second théorème de Bernoulli,

Cette "vérification" est de peu d'intérêt, le Théorème Central Limite (formulé correctement, pas de la façon dont vous le faites) est bien connu. Contrairement à ce que vous répétez en boucle, plusieurs simulations que j'ai faites récemment illustrent ce résultat :
- celle sur le nombre d'occurrences de pile en n tirages à pile ou face : https://dlz9.forumactif.com/t2121p100-pile-ou-face-une-realite-dans-les-simulations#25302
- celles sur le nombre de noyaux radioactifs parmi n non désintégrés au bout d'un tenps donné : https://dlz9.forumactif.com/t2091-l-aiguille-de-buffon#24647
Ces simulations là présentent au moins l'avantage de ne pas avoir de bug.

Vous êtes vraiment insultant.

Code:

int main() // suivant 201
{
// simulation de courbe de Gauss avec pile ou face
  randomize();
  int Res128[128]; //c'est à dire 2^7
  for (int i=0; i<128; i++) Res128[i]=0;
  for (int i=0; i<100000; i++)
  {
    int nb=0;
    for (int j=0; j<7; j++)
    {
      int r=rand()%100;
      if (r < 50) r=0;
//      int r=rand()%2;
//      if (r < 1) r=0;
      else r=1;
      switch (j)
      {
        case 0: nb+=r; break;
        case 1: nb+=r*2; break;
        case 2: nb+=r*4; break;
        case 3: nb+=r*8; break;
        case 4: nb+=r*16; break;
        case 5: nb+=r*32; break;
        case 6: nb+=r*64; break;
      }
    }
    Res128[nb]++;
  }
  AfficheNormale(espion, Res128, 128, "\nNombres crés par Pile ou fce calculé avec %100\n");
// version de controle
  for (int i=0; i<128; i++) Res128[i]=0;
  for (int i=0; i<100000; i++)
  {
    int r=rand()%128;
    Res128[r]++;
  }
  AfficheNormale(espion, Res128, 128, "\nNombres version de base calculés avec %128\n");
  fclose(espion);
  return 0;
}


Merci pour le code.

J'ai deux petites questions :
1) Que fait randomize() ? Ça initialise le générateur de nombres pseudo-aléatoires ? C'est du Turbo C ?
2) Pourquoi pas seulement
int r = rand()%2
Ça suffit à retourner un entier qui vaut 0 ou 1, n'est-ce pas ? Je ne comprends pas à quoi servent les lignes suivantes
if (r < 1) r=0;
else r=1;

Mais il s'agit de détails. Je ne vois a priori pas de problème dans le code. Deux petits tests :
1°) Si vous essayez le modulo 2 sans les deux lignes inutiles, ça donne le même résultat pour l'écart-type ?
2°) Si vous faites 10000 tirages au lieu de 100000 :
for (int i=0; i<10000; i++)
est-ce que vous trouvez un écart-type pas trop loin de 8.8 ou nettement plus petit ?

Reste la piste du problème avec le générateur, problème sur le bit de poids faible (celui qui intervient dans le modulo 2). Là, ce n'est pas mon rayon.

Bonsoir,
Là j'ai eu la confirmation que vous n'avez rien compris.
Vous n'avez même pas la moindre critique à formuler, là vraiment vous baissez.
Si vous lisez soigneusement ce que j'ai écrit, pas le code naturellement, de nombreuses fois, ça rentrera peut-être. Mais si vous le lisez comme vous lisez les autres documents, avec la seule préoccupation de me contredire, alors il n'y a aucune chance que vous compreniez quoi que ce soit, cf. la corde de Bertrand, le cours de Levallois.

Bonjour,

Pourriez-vous réponde à ma question concernant le cas modulo 2  ?

Pourquoi pas seulement
int r = rand()%2
Ça suffit à retourner un entier qui vaut 0 ou 1, n'est-ce pas ? Je ne comprends pas à quoi servent les lignes suivantes
if (r < 1) r=0;
else r=1;

Je vous ai proposé deux petits tests que vous pouvez réaliser sans problème :

1°) Si vous essayez le modulo 2 sans les deux lignes inutiles, ça donne le même résultat pour l'écart-type ?
2°) Si vous faites 10000 tirages au lieu de 100000 :
for (int i=0; i<10000; i++)
est-ce que vous trouvez un écart-type pas trop loin de 8.8 ou nettement plus petit ?

Vous avez mentionné une référence :

Dlzlogic a écrit:D'ailleurs l'article qui parlait de ce point ne donnait pas d'autre solution.

De quel article parlez-vous ? Cet article parlait des défauts du générateur que vous utilisez ? Pourriez vous donner cette référence ?

Bonjour,
De temps en temps, vous devriez lire ce que j'écris. Mais pas grave, je me répète.

Humx3 a écrit:Pourquoi pas seulement
int r = rand()%2
Ça suffit à retourner un entier qui vaut 0 ou 1, n'est-ce pas ? Je ne comprends pas à quoi servent les lignes suivantes
if (r < 1) r=0;
else r=1;

Parce que c'était le but de mon test. Comparer un calcul où il y aurait beaucoup de 0 et 1 dont je connais le résultat grâce à la formation de nombres de 0 à 127, d'une part en utilisant mod(2) d'autre part en utilisant mod(100). J'ai eu confirmation de la différence non négligeable.
Comme vous refusiez catégoriquement de comprendre ce que j'expliquais, j'ai ouvert ce fil et j'ai ressorti la vérification de la loi des grand nombres et le test de mots de sept 0 ou 1 pour former des nombres et ainsi vérifier le second théorème de Bernoulli connu sous le nom de loi normale.
C'est à dire que on disposant d'une vérification de la base fondamentale de la théorie des probabilités.

Les discussions concernant les générateurs sont inutiles pour les raisons suivantes :
1- il est difficile de trouver le module de base d'un générateur. La plupart sont basés sur une formule récurrente. Chaque éditeur de logiciel a ses deux paramètres. Autrefois Wikipédia donnait ces deux paramètres pour différents compilateurs et langages divers. J'ai observé des anomalies caractérisées dans certains logiciels, mais je n'ai pas réussi à trouver les sources.
2- le dernier module de générateur que j'ai pu observer, je crois chez Python était astucieux mais très discutable.
3- les générateurs utilisés pour la cryptographie dépassent mes compétence et ne me concernent pas.
4- je n'ai pas trouvé de test de générateur documenté et utilisable
5- le générateur GenRand est une insulte à la théorie des probabilités et c'est celui-là que certaine que je connais recommande.
6- pour nos utilisations expérimentales et sans conséquence, les générateurs utilisés conviennent
7- l'article auquel j'ai fait référence concernant mod(2) pour obtenir 0 ou 1 concernant les générateurs de base (deux paramètres). Je suppose que c'est lié à la représentation binaire des nombres et des calculs dans la machine.
8- il est comique de supposer que le générateur de Borland est veux et obsolète.

Conclusion : si on dispose d'un système de test de générateur issu d'une autorité compétente, alors on pourra discuter.
Dans le cadre de ce fil, la question importante est la vérification des deux théorèmes de Bernoulli : loi des grands nombres et loi normale.