Générateur de pseudo-aléatoire ou décimales ?

J'avais proposé un petit exercice de codage à Dlzlogic, à propos de sa lubie des générateurs de nombres pseudo aléatoires qui trichent :

Je propose donc l'expérience suivante : on fait jouer pi à pile ou face : décimale paire = pile, décimale impaire = face. On peut disposer comme ça d'un million de tirages à pile ou face avec un million de décimales de pi.
Joueur A : parie sur le retard (si pile est en avance, parie face)
Joueur B : parie sur l'avance (si pile est en avance, parie pile)
Joueur C : parie toujours pile
Joueur D : parie la même chose que le tirage précédent

On représentera sur un graphique le nombre de paris gagnés moins le nombre de paris perdus par chaque joueur, en fonction du nombre de tirages (c.-à-d. de décimales de pi).

On pourra, pour varier les plaisirs, recommencer avec racine(2), avec e.

Mais ça ne l'a pas intéressé.

Alors j'ai fait les trois graphiques avec les décimales de pi, racine(2) et e. J'en ai aussi fait trois autres avec des tirages au moyen du générateur de pseudo-aléatoire de python. Voici les six graphiques obtenus. Saurez-vous reconnaître quel graphique est obtenu avec les décimales de quel nombre, quels graphiques sont obtenus avec le générateur de python ?

Très joli tes 6 graphiques.
J'ai dit que je ne voulais plus parler des tirages à pile ou face, mais le joue le jeu, contrairement à toi, puisque je réponds toujours.
Donc, je pense que les résultats 1, 2 et 5 ont été faits avec le générateur de Python.
Mais si on veut tester la qualité d'un générateur, c'est pas avec de jolies images, mais avec des nombres, c'est à dire des mathématiques.
On détermine un protocole, c'est à dire le détail des tests à réaliser, les résultats prévus et les tolérances admises.
Tant qu'on n'aura pas fait cela, ce ne sera que de l'amusement.
Actuellement, je ne sais pas exactement la philosophie de GenRand. Un test amusant à faire : les mêmes 6 expériences, mais en sautant 2 coups sur 3.
Par contre, les résultats numériques des simulations de Sylviel prouvent de façon certaine que le tirage c'est pas aléatoire mais résulte d'un algorithme bien précis.

Dlzlogic a écrit:
Donc, je pense que les résultats 1, 2 et 5 ont été faits avec le générateur de Python. 

Deux mauvaises réponse sur trois.

Par contre, les résultats numériques des simulations de Sylviel prouvent de façon certaine que le tirage c'est pas aléatoire mais résulte d'un algorithme bien précis.

Quelle preuve ?
Par définition même, un générateur de pseudo aléatoire ne fait pas de l'aléatoire. Mais j'aimerais bien savoir quel critère tu appliques pour décider que ce n'est pas de l'aléatoire au vu des résultats.

N.B. Les variables aléatoires "nb de paris gagnés - nb de paris perdus au bout d'un million de tirages" ont toutes les quatre même loi, qui est à peu près une loi normale centrée d'écart type 1000.

Le qualificatif "pseudo" veut simplement dire que le système est cyclique et que telle séquence sera toujours suivie de la même chose.
Pour les générateurs ordinaires, le cycle est d'environ 4 milliards, donc à part les traitements sensibles, cela n'a aucune importance.
Concernant la seconde question : j'ai observé que l'écart entre les valeurs observées et les valeurs théoriques étaient de l'ordre de 2%, que ce soit à partir de statistiques réelles ou de générateur "ordinaire". Par contre, les résultats donnés par les traitement faits par Sylviel ont 4 chiffres significatifs exacts, ce qui montre bien que ça ne résulte pas de tirage aléatoire. Ce n'est pas du tout subjectif.
Le source de GenRand est compliqué à comprendre, d'autant que la fonction comporte de nombreux paramètres, ce qui rend la fonction variable suivant le programme qui l'appelle. Naturellement les auteurs ont tout fait pour rendre la compréhension presque impossible.
Petit détail supplémentaire, un traitement avec 1 million de valeurs, alors qu'il n'y a que 2 issues n'est pas souhaitable.
Ce n'est pas pour rien que j'évoque ce problème depuis longtemps. Ce fichier des températures est une aubaine pour moi. Jusque maintenant je n'avais à ma disposition, comme données incontestables, qu'une série de 484 valeurs, que personne ne m'a d'ailleurs jamais demandée. On se contente de me répondre "c'est pas vrai".

J'ai oublié un détail important : avec un tirage à 2 issues, il faudrait vraiment le faire exprès pour qu'un générateur très mauvais ne produise pas un résultat relativement aléatoire. La même expérience avec des nombres en base 10 ou en base 100 serait plus significative.

Dlzlogic a écrit:
Concernant la seconde question : j'ai observé que l'écart entre les valeurs observées et les valeurs théoriques étaient de l'ordre de 2%, que ce soit à partir de statistiques réelles ou de générateur "ordinaire". Par contre, les résultats donnés par les traitement faits par Sylviel ont 4 chiffres significatifs exacts, ce qui montre bien que ça ne résulte pas de tirage aléatoire. Ce n'est pas du tout subjectif.

Encore une fois ce fameux 2% sorti du chapeau. Tu n'as jamais expliqué d'où tu tires ce 2% (je te l'ai déjà demandé).
En gros, ton opinion est : un résultat de simulation cohérent avec la prédiction théorique est forcément obtenu au moyen d'un générateur qui triche. Je ne qualifierais pas cette opinion de "subjective". Juste "absurde".

Quelques autres jolis dessins. Cette fois-ci, je fais 200 séries de 10 000 tirages, et je représente les histogrammes des gains de A, B, C, D sur ces 200 séries. Je l'ai fait 4 fois, deux fois avec des tirages donnés par les décimales de e et de racine(2), deux fois avec des tirages donnés par le générateur de pseudo-aléatoire de python. Même question : qui est quoi ?

À chaque fois, la loi est à peu près normale centrée d'écart-type 100.

Oui, c'est vrai c'est absurde.

Bonsoir,

Ça m'a enfin convaincu : Gbzm aime les dessins en couleurs.

Bonne soirée.

Bon, pour essayer de positiver un peu, j'aimerais bien que GBZM propose un protocole pour vérifier que tel générateur de nombres aléatoires produit une suite de nombres aléatoires.
J'insiste sur le terme "suite" et sur le terme "aléatoire".
Deux précisions, d'abors il faut définir les conditions qu'une suite des nombre est effectivement aléatoire, ensuite travailler sur des résultats du type binaire me parait difficile à exploiter. il vaut mieux travailler avec des nombres en base 10 ou en base 100, ce qui est très facile avec les décimales de nombres tels que pi, e, rac(2). J'ai cru comprendre que ces listes étaient disponibles sur le net.
Parallèlement, on pourra comparer avec des séries résultant du fichier des températures, naturellement en appliquant les corrections climatiques et saisonnières.
Bien-sûr, j'ai des protocoles à proposer, mais je ne veux pas les imposer.
Pour mémoire, j'ai posé cette même question à Sylviel un grand nombre de fois, mais il n'a rien proposé. Les résultats de mes vérifications, donc suivant mes protocoles, il les a toujours refusés, ou plutôt, tout simplement ignorés.

Le générateur de nombres pseudo-aléatoires utilisé par python a été testé intensivement pas la communauté scientifique, en particulier au moyen des tests "Diehard"
https://en.wikipedia.org/wiki/Diehard_tests

Si tu as d'autres protocoles à proposer , propose. À condition d'être clair et explicite, et d'accepter de publier tes codes de simulation.

Bonjour GBZM,
Décidément; tu veux pas te mouiller.
Moi, je réponds.
D'abord au niveau binaire. Là il faut un assez grand nombre de tirages on compte les suites de même parité, c'est à dire les suites de 1, de 2 pareil, de 3 pareil etc.et on compare, d'une part avec les valeurs théoriques et avec d'autres générateurs.
La répartition des nombres d'occurrences, on dispose de suites aléatoires réelles, pi, e, rac(2). On peut le faire facilement en base 10 et en base 100.
Un mixe binaire/suites. On groupe les résultats consécutives en mots de 7, on obtient alors des nombres en base 2, de 0 à 63. On étudie la répartition de ces nombres.

En fait le problème c'est de savoir ce qu'on veut obtenir, ce qu'il faut obtenir, si on admet que les suites des décimales sont aléatoires et si on peut les considérer comme norme de comparaison.
Autre position Diehard a été testé, donc c'est bon et tous les autres sont faux, y compris naturellement les décimales de pi.
A toi de dire. C'est toi qui a ouvert ce fil, tu dois avoir une idée derrière la tête. Si c'est la méthode du rattrapage qui t'intéresse, j'au aussi une méthode pour tester.
Par ailleurs, il serait intéressant que tu précises en quelques mots ce que tu attends d'un générateur de nombres aléatoires.

Autre position Diehard a été testé, donc c'est bon et tous les autres sont faux, y compris naturellement les décimales de pi.

Que veut dire cette phrase ? Tu as l'air de penser que Diehard est un générateur de pseudo aléatoire ?
Diehard est une batterie de tests pour vérifier la qualité des générateurs de pseudo-aléatoire

On groupe les résultats consécutives en mots de 7, on obtient alors des nombres en base 2, de 0 à 63.

Sur 7 bits, ce sont les entiers de 0 à 127 qui sont codés  (2^7 =128).

Je poursuis ma petite série de qui es quoi : cette fois-ci, des histogrammes du nombre d'occurrences de suites de 3 chiffres, dans un million de décimales de pi ou e ou racine(2) ou dans un million de chiffres tirés au hasard par le générateur de python.

Oui, pardon pour la faute, avec 7 bits, c'est bien de 0 à 127.
Très bien tes histogrammes, mais si tu disais la raison de tes calculs, ce serait plus intéressants.

C'est toi qui souhaitais étudier les occurrences de suites de 3 chiffres. Maintenant que tu vois que ça ne donne rien pour distinguer les suites de décimales de nombres comme pi, e racine(2) et les suites de chiffres tirés aux hasard par le générateur de python, ça ne t'intéresse plus, bien sûr.

Pour faire des tests il faut préciser les hypothèses et se mettre d'accord.
Toi, tu joues aux devinettes. C'est ton droit, mais tu auras du mal à trouver avec qui jouer.
La question que je pose est simple.
1- L'affirmation "toute expérience aléatoire [...] produit une liste normale.
2- si l'affirmation 1 est vraie, alors on peut la vérifier dans un grand nombre de situations, les décimales de nombres irrationnels, les relevés de température, et d'une façon générale tout fichier de statistique honnête et sans faute.
3- Soit un générateur de nombres pseudo-aléatoires : établir un protocole de tests qui vérifie qu'il simule effectivement des expériences réelles. Les tests doivent naturellement donner des résultats numériques. De façon évidente la seule loi connue par ces simulation est celle du hasard.