Le générateur aléatoire de Dlzlogic

Salut,

@Dlzlogic : J'ouvre ce fil pour essayer de comprendre pourquoi, ton générateur bug.

Déjà, quel expérience te fait dire que ton générateur déraille ?

Bonjour Dattier,
D'abord, je ne pense pas qu'un générateur de nombre aléatoires puisse "dérailler".
Malheureusement, je n'ai pas trouvé de document complet sur les générateurs. Si quelqu'un veut dire que mon générateur déraille, c'est à lui de le prouver. Pour cela, il faudrait qu'il y ait une norme, ce qui n'est pas le cas, à ma connaissance.

Comme je l'ai dit, j'ai lu un article qui mettait en garde les utilisateurs à propos de l'utilisation de mod(2) pour faire des tests du type 0-1.
A l'occasion d'une simulation ou j'utilisais cela, j'ai profité du fait que je faisais un très grand nombre d'appels pour faire le test.
Il n'y avait pas d'écart sur la moyenne, par contre les résultats étaient meilleurs, donc la dispersion moins grande avec la formule mod(2) qu'avec mod(100). En d'autres termes, il n'y avait pas de plus ou moins vrai mais de différence de résultats suivant la formule utilisée.
En toute logique, un résultat plus concentré ne pouvait pas être un défaut.
Ca m'a tracassé. J'ai une petite idée concernant la raison, mais sauf si je trouve une preuve, je la garde pour moi.

Rétablissons les faits (vérifiables).

1°) Dlzlogic propose une expérience : on tire sept fois à pile (=1) ou face (=0) et avec ces 7 bits on fabrique l'entier entre 0 et 127 dont c'est l'écriture binaire. On répète cela 100 000 fois en notant les occurrences des 128 entiers. On a ainsi un total de 128 nombres d'occurrences.
https://dlz9.forumactif.com/t2138-jouons-a-pile-ou-face#25345

2°) Analysons cette expérience. Le tirage d'un entier entre 0 et 127 au moyen de ses 7 bits est un tirage uniforme : chaque entier a probabilité 1/128 de sortir. D'accord ?
Le nombre d'occurrences N_a d'un entier a donné en 100 000 tirages d'entiers est donc la somme de 100 000 variables aléatoires de Bernoulli indépendantes valant 1 avec probabilité 1/128 et 0 avec probabilité 127/128. N_a est donc une variable aléatoire binomiale de paramètres 100 000 et 1/128. Son espérance est 100 000/128 = 781.25 et sa variance est 100000*127 / 128², ce qui fait un écart-type de 27.84.... C'est ce que j'explique dans ce message :
https://dlz9.forumactif.com/t2138-jouons-a-pile-ou-face#25350
D'accord ?

3°) Or l'écart-type constaté par Dlzlogic est 16.72, bien trop loin du 27.84. Voir ici la valeur de l'emq : https://dlz9.forumactif.com/t2138-jouons-a-pile-ou-face#25345. C'est pourquoi je signale immédiatement qu'il y a un bug. La faute dans le code de la simulation étant écartée, il ne reste que le problème de la production aléatoire des bits par le rand()%2 sur l'installation de Dlzlogic. Ce diagnostic est confirmé par les simulations
- faites par Dlzlogic avec un rand()%100
- faites par moi en python
- faites par moi en C++ avec un rand()%2 fourni par un générateur de nombre pseudo-aléatoire plus récent.
qui donnent toutes des écarts-type cohérents avec le 27.84 théorique.
Dattier, vous pouvez faire vous même la simulation (avec Maple, puisqu'il semble que c'est votre outils préféré), vous verrez ce qu'il en est.
D'accord ?

On a donc bien la preuve que le générateur de nombres pseudo-aléatoires de l'installation de Dlzlogic a un défaut portant sur le bit de poids le plus faible (celui donné par le modulo 2) quand on fait appel à lui plusieurs centaines de milliers de fois.
C'est pourquoi il aurait été intéressant d'avoir le résultat de l'expérience que je proposais dans ce fil :
https://dlz9.forumactif.com/t2158-series-de-10-lancers-avec-au-plus-3-piles
Mais Dlzlogic refuse catégoriquement de la faire, alors qu'il le pourrait très facilement. Pourquoi ce refus ?

J'ai une petite idée concernant la raison,..., je la garde pour moi.

J'ai regardé sur le Net "rand C++" il y a beaucoup de références. L'une d'elle devrait bien compléter votre argumentation.

@Dlzlogic : si le sujet ne t'interesse pas, tu peux fermer cette discussion, cela ne me dérange pas du tout.

Bonjour,
Si quelqu'un peut me dire
1- comment il est sûr que mon générateur ne serait pas bon, je voudrais bien qu'il m'explique ce qui fait qu'il en est sûr, quel test
2- comment il me propose d'y remédier, par exemple en modifiant les deux paramètres de calcul. Lesquels prendre ?

Je rentre à l'instant je vais lire des liens disponibles.

PS J'ai lu certains articles, outre le fait que les générateurs semblent de la magie pour certains, je n'ai rien trouvé de particulier à citer.

Je renouvelle ma question : qu'est-ce qui vous fait dire que mon générateur est mauvais et si c'était le cas, quel serait pour vous l'inconvénient ?

En fait, je suis parfaitement de mauvaise foi. Quand je pose des questions concernant ce sujet, je sais parfaitement qu'il n'y aura pas de réponse.
Concernant le générateur lui-même il est vieux mais la méthode de base est toujours la même. En d'autres termes, il ne présente aucune anomalie, tout simplement, parce qu'il est aléatoire, or, que le sache, sauf pour l'interprétation de la corde de Bertrand, l'aléatoire ne dépend pas du choix du matheux qui évoque le sujet.
Concernant la raison pour laquelle certains sont si agressifs et si sûr d'eux, c'est tout simplement parce que à l'occasion de discussions, je réalise des simulations. Comme ces simulations confirment mes propos et que à l'unanimité de certains, j'ai tort, comme je suis honnête et que je ne me contredis pas, c'est forcément "mon" générateur qui a tort.

Concernant la raison pour laquelle certains sont si agressifs et si sûr d'eux, c'est tout simplement parce que à l'occasion de discussions, je réalise des simulations. Comme ces simulations confirment mes propos et que à l'unanimité de certains, j'ai tort, comme je suis honnête et que je ne me contredis pas, c'est forcément "mon" générateur qui a tort.

Petite correction : tu réalises de temps à autres des simulations, qui généralement contredisent tes propos, mais tu leur fait dire ce que tu veux (on peut te ressortir tes histogrammes
avec des % théoriques et réalisé très différents mais qui te semblait concluant malgré tout )
Nous n'avons jamais dit que c'était ton générateur qui avait tort (en revanche tu as longtemps prétendu que le générateur aléatoire de python trichait / était faux etc...)

Et sinon tu passes ton temps à te contredire, mais tu ne t'en rends pas compte...

comment il est sûr que mon générateur ne serait pas bon, je voudrais bien qu'il m'explique ce qui fait qu'il en est sûr, quel test

Vous n'avez pas lu ici : https://dlz9.forumactif.com/t2160-le-generateur-aleatoire-de-dlzlogic#25600 ?
Comment expliquez vous
- que le calcul théorique donne un écart-type de 27.84
- que toutes les simulations, celles faites par vous avec rand()%100 ou en tirant directement l'entier avec %128, celles faites par moi avec rand()%2 ou rand()%100, celles faites par moi avec python, donnent un écart-type compatible avec ce 27.84 (pour mémoire vous trouvez 27.55),
- que seule la simulation avec le rand()%2 de votre installation donne un écart-type de 16.72.

En fait, je suis parfaitement de mauvaise foi.

Merci, mais je m'en suis bien rendu compte.

En d'autres termes, il ne présente aucune anomalie, tout simplement, parce qu'il est aléatoire

Vous savez parfaitement qu'un générateur de nombres pseudo-aléatoires n'est pas aléatoire, mais déterministe ; seule la graine varie, toute la suite est entièrement déterminée à partir de la graine.
Vous arrivez très bien à prouver votre mauvaise foi.

Bonsoir Humx3,

h a écrit:Comment expliquez vous
- que le calcul théorique donne un écart-type de 27.84
- que toutes les simulations, celles faites par vous avec rand()%100 ou en tirant directement l'entier avec %128, celles faites

La définition de l'écart type est très claire : c'est la racine carrée de la somme des carrés de la différence entre les valeurs et la moyenne arithmétique. Si le résultat de ce calcul est inférieur à votre valeur théorique ce n'est pas de ma faute. Si le résultat en utilisant mod(100) est différent, ce n'est pas de ma faute. Il est vrai qu'il peut être intéressant d'en trouver la raison mathématique incontestable, mais je n'en sui pas sûr et vous avec vos certitudes vous êtes vraiment loin d'avoir une possibilité de trouver cette explication.

J'ai utilisé cette méthode de calcul, à savoir la création de nombres indépendamment de tout autre artifice, en particulier mon générateur mis sur la sellette depuis 20 ans, d'où l'utilisation de nombres en binaire, aucuns simulation contradictoire n'était acceptée las seule chose sûr : j'avais tort.

Bon très nettement, on est très loin de discussion mathématique. C'est votre choix. Allez-y, régalez-vous.

Sur un plans strictement mathématique, comment pourriez- vous justifier que un anomalie de générateur sur des tirages type pile ou face aint une influence sur la répartition des nombres décimaux formés à partir de la succession de 0 et de 1.
Ceci est une question précise posée à un mathématicien, elle nécessite une réponse précise et argumentée.
Ceci est une question précise posée à un mathématicien, elle nécessite une réponse précise et argumentée.

Si le résultat de ce calcul est inférieur à votre valeur théorique ce n'est pas de ma faute. Si le résultat en utilisant mod(100) est différent, ce n'est pas de ma faute.

Encore une fois, ne confondez pas calcul et simulation. N'oubliez pas non plus de dire que TOUTES LES SIMULATIONS, SAUF CELLE RÉALISÉE AVEC VOTRE RAND()%2, DONNENT UN RÉSULTAT CONFORME AU CALCUL THÉORIQUE.
Ce n'est bien entendu pas de votre faute, ce n'est pas vous qui avez écrit le générateur de nombres pseudo-aléatoires que vous utilisez.

Sur un plans strictement mathématique, comment pourriez- vous justifier que un anomalie de générateur sur des tirages type pile ou face aint une influence sur la répartition des nombres décimaux formés à partir de la succession de 0 et de 1.

On a la preuve que la suite de 100 000 entiers entre 0 et 127 que votre rand()%2 produit a une caractéristique (l'écart-type) bien différente de celle d'une suite de 100 000 entiers tirés indépendamment et uniformément entre 0 et 127.
La question est donc : quel est le défaut sur le rand()%2 qui explique cette anomalie constatée sans contestation possible ? D'où vient exactement le problème ? Une période trop courte sur le bit de poids faible ? C'est probable, mais je n'en suis pas sûr. Le problème a visiblement été documenté, mais vous ne retrouvez pas l'article que vous aviez lu. À votre place, je réaliserais d'autres expériences, notamment sur la période du rand()%2. Mais je ne suis pas à votre place, et vous refusez catégoriquement de faire des expériences complémentaires qui pourraient donner des informations intéressantes.

Bonne nuit.

Oh, je n'ai jamais refusé de faire des simulations, mais j'ai toujours observé que toute action de ma part se retournait systématique contre moi. Même la tentative de "Pivot" en me proposant un système linéaire tordu.
Bravo les matheux, vous êtes vraiment des champions.
Petit hors sujet : vous êtes incapable de comprendre des histoires basiques comme les cordes de Bertrand ou le rattrapage et vous continuer à la ramener, c'est tout de même merveilleux.
J'ai bien compris votre méthode, c'est du plus bas niveau.
Concernant l'histoire du générateur : trouvez la formule de base, et on en reparle.

Bonjour,

Dlzlogic a écrit:Oh, je n'ai jamais refusé de faire des simulations

Mensonge avéré. Le lundi 15 juillet :
https://dlz9.forumactif.com/t2158-series-de-10-lancers-avec-au-plus-3-piles#25567
Moi : Oui ou non, avez-vous l'intention des réaliser les expériences que je vous ai demandées ?
Dlzlogic : Si c'est pour émettre des jugements sur les générateurs, alors c'est NON.

Et baratin habituel "vous ne comprenez rien".

La définition de l'écart type est très claire : c'est la racine carrée de la somme des carrés de la différence entre les valeurs et la moyenne arithmétique.

Caramba, encore raté !

vous êtes incapable de comprendre des histoires basiques comme les cordes de Bertrand ou le rattrapage et vous continuer à la ramener, c'est tout de même merveilleux.

Ce qui est merveilleux c'est que tous tes interlocuteurs (sauf Dattier, qui aime entretenir ton délire), tous les livres (y compris Harthong) disent la même chose sur le rattrapage ou la corde
de Bertrand, et ne vont pas dans ton sens. Mais tu continue de la ramener...

Bonjour,
Oui, il est vrai que j'ai refuse dans ce cas précis, et j'ai donné la raison.
Par contre il est clair que si Humx3 avait répondu comme on pourrait l'attendre d'un individu normal, poli et scientifique j'aurais peut-être changé d'avis.
La nuit portant conseil, j'ai eu une idée pour vérifier mon hypothèse. Cette hypothèse deviendra "preuve" éventuellement si je la juge ainsi et Beagle pourra compléter la citation qu'il a tronquée. Beagle est d'ailleurs un bon élève il agit comme ses maîtres.
Mais il faut me laisser un peu de temps.

"Beagle est d'ailleurs un bon élève il agit comme ses maîtres."

C'est un fait qu'en mathématiques je me positionne élève et j'ai donc plein de maitres.

Toi Pierre tu es en dehors, ni élève, ni maitre.
Donc pas de théorie, pas de pratique qui doit répondre à la théorie.
C'est pratique.

Juste une question sur ton générateur d'aléatoire.
Tu parles d'un générateur d'il ya 20 ans ou plus , toujours celui là
ou bien tes résultats étranges d'après GBZM sont issus d'une version récente ?

@ Beagle,
Mon compilateur date de 2002, c'est toujours le même. Pourquoi cette question ? as-tu la moindre idée de la façon dont fonctionne un générateur ? Sais-tu par exemple la différence entre un générateur comme GenRand et un générateur honnête ? Comment ferais-tu pour tester un générateur Etc.
Bien-sûr beaucoup trop de questions pour toi. La seule chose que tu sais dire "Dlzlogic dit des choses qui ne sont pas dans ma logique, ça ne peut donc pas être vrai, comme il les confirme avec son générateur, c'est que celui-ci est mauvais". Logique implacable.

Pour l'ancienneté du générateur,
ben de mémoire ils ont changé de générateur car il y avait des problèmes pour le C++ je sais plus trop je connais pas
cela fait un moment qu'on avait parlé de cela,
je ne vais pas rechercher sur le web mais les forums parlaient de soucis.

Si tous les logiciels de excel, matlab, python, R utilisent du Mersenne Twister
c'est qu'ils en sont content.
Je n'étais pas sur pour R donc copilot me l'adit R est passé en 2014 à Mersenne Twister,
donc tu vois que 2002, il n' ya pas de honte à avoir changé dans le C++ de 2002.

Ensuite il faut lire les bons auteurs: Dattier

je n'ai plus sa phrase,
mais un générateur qui contredirait la théorie serait éliminé.

reste à changer de théorie, et que celle-ci soit consistante.
Pour toi Pierre, pas de théorie, donc pas de possibilité de falsifier un générateur.
On peut le prendre comme on veut.

Beagle a écrit:Pour toi Pierre, pas de théorie, donc pas de possibilité de falsifier un générateur.

C'est là que tu te trompes. Je connais bien la théorie, j'ai même réussi à comprendre le but de GenRand, mais pas tout à fait comment ils avaient fait.
Peux-tu expliquer ce qui te gène dans le fait que mon générateur soit vieux et ait un problème dans l'utilisation de mod(2). Au contraire, ça de donne une occasion de dire que j'ai tort.

Bah c'est simple, si ton générateur aboutit à une valeur qui n'est pas celle de la théorie,
ben c'est qu'il a un soucis dans cet usage précis au moins.

Lorsque l'on dit vous pouvez utiliser les décimales de pi ou de racine de deux comme générateur d'aléatoire (en dehors idem du point de départ (re)connu)
c'est que cela ne donne pas de résultats qui contredisent la théorie.

Mersenne Twister a été introduit dans le C++11 donc en 2011

La période longue d’un générateur de nombres pseudo-aléatoires (PRNG) fait référence au nombre de valeurs uniques que le générateur peut produire avant de recommencer à générer les mêmes valeurs. En d’autres termes, c’est la longueur du cycle de valeurs générées avant que le PRNG ne se répète.

Plus précisément, pour un PRNG comme le Mersenne Twister, la période longue est déterminée par le nombre de bits dans l’état interne du générateur. Le Mersenne Twister a une période de \(2^{19937} - 1\), ce qui signifie qu’il peut générer \(2^{19937} - 1\) valeurs uniques avant de revenir au début du cycle.

En pratique, une période longue est souhaitable car elle garantit que les séquences de nombres générées sont moins susceptibles de se répéter rapidement, ce qui est important pour des applications telles que la simulation, la cryptographie et les jeux. Un PRNG avec une période courte pourrait entraîner des comportements prévisibles et indésirables.