Forum de mathématiques - Bibm@th.net

oui, c'est effectivement très important (et dans le sujet de la discussion), mais je ne suis pas spécialiste des tests de validité de générateurs. Mais bon....

On a  sous les yeux  \( x_1 , ... x_n \)

Une loi normale est déterminée par sa moyenne (ie l'espérance) et son écart-type.

Si on connaît la moyenne par théorie (ou autre justification), alors tant mieux, mais si on ne la connait pas, alors on approche sa valeur par la moyenne arithmétique \(m\) de liste.

Si on connaît l'écart-type par théorie (ou autre justification), alors tant mieux, mais si on le connait pas, alors on approche sa valeur grâce aux éléments de la liste avec la formule \( \frac{1}{n}\sum_{i=1}^n  (x_i - m)^2 \) (=écart-type de la liste) si m est la vraie valeur de l'espérance de la loi, et avec la formule \( \frac{1}{n-1}\sum_{i=1}^n  (x_i - m)^2 \) si m n'est qu'une valeur approchée de l'espérance de la loi. Disons qu'on a obtenu la valeur \(s\) par un moyen ou un autre.

Ainsi, on obtient deux  valeurs m et s qui se veulent être (proche de) l'espérance et l'écart-type de la loi normale.
Il reste maintenant à vérifier que \( x_1 , ... x_n \) est conforme à la loi N(m,s). Là, on peut comparer la fonction de masse de la loi N(m,s), à savoir \( \frac{1}{s.\sqrt{2 \pi}}\exp(\frac{-1}{2}(\frac{x-m}{s})^2) \),  et un histogramme de fréquences de  \( x_1 , ... x_n \) (par exemple avec 10 classes comme tu le fais, mais si n est assez grand, on peut augmenter le nombre de classes pour être plus précis).

Là, tu as l'histogramme de la loi uniforme.

là c'est une loi "triangulaire" : https://docs.scipy.org/doc/numpy-1.10.0 … gular.html

Là, une loi de Poisson : https://docs.scipy.org/doc/numpy-1.10.0 … isson.html

etc. il y en a des tonnes !

oui et tu remarqueras le rapport \( \simeq \sqrt 2 \) entre emqMoy de 8000 et celui de son double 16000,
et le même rapport entre emqMoy de 16000 et celui de son double 32000.

Oui, je comprends ta remarque, même si hier j'en étais étonné.

On comprend très bien que, mathématiquement, la question du langage informatique n'a pas lieu de poser, puisque les maths ne dépendent pas d'un logiciel informatique. Il ne peut y avoir un bon résultat pour les langages compilés et un autre résultat complètement différent mais bon pour les langages interprétés. En réalité, il n'y a qu'une seule vraie bonne valeur.

Mais en effet, il se peut que des versions "buggées" de logiciels donnent un mauvais rand. "Mon C" (qui compile) donne des résultats conformes à la valeur théorique. Pour ma part, je ne peux expliquer où serait le "bug" dans les langages informatiques, je ne suis pas assez à l'aise dans ces langages C, C++ pour être sûr de moi sur une explication nette sans bavure.

J'aimerais bien mettre la main sur un langage qui ne donne pas une moyenne de l'emq tournant autour de 30 (pour 16000 tirages), histoire d'étudier la situation.

On voit bien que javascript, maple, c++, python, "mon C" donne 30, alors que DevC++ et "ton C" donne 23 ou 25.  Aucunes des simulations n passe de 30 à 25 ou de 25 à 30.
Entre 25 et 30, il y a une grosse différence, suffisante à mon avis pour conclure à de mauvaises fonctions random.

Je n'ai jamais dit cela... je te dis que le nombre d'observations ne varie pas ! C'est le nombre de variables sommées qui change (12000 ou 16000 ou 32000). Ce que nous observons, c'est la somme \(X_1 + ... + X_{16000} \) pour 16000. Si on augmente à 32000, on n'augmente pas le nombre d'observations, on change d'objet observé car la somme \(X_1 + ... + X_{32000} \)  change en nombre de termes.
D'ailleurs, la moyenne de la somme change 32000 / 16 = 2000, et non 1000 : c'est une preuve qu'on n'observe plus la même chose. :)

Bref, on n'augmente pas le nombre d'observations, mais on change l'objet observé. J'espère être assez limpide.

Ok, mais dans le programme, on divise par 16 (toujours par 16) , et par 100 (toujours par 100). Ni 16, ni 100 ne tendent vers l'infini. Donc ce n'est pas un raisonnement ad hoc dans notre cas.

oui, ce serait intéressant.

Comme je te l'ai dit, on ne change pas le nombre d'observations ! Regarde par quoi on divise dans le programme : ce n'est pas par 16000 ou 32000...

Les statisticiens savent très bien que l'écart-type d'une somme \(X_1 + ... + X_k\) de k variables indépendantes augmente quand k augmente : on dit (tu le sais toi aussi !) que les écart-types s'ajoutent quadratiquement (autrement dit, les variances s'additionnent). Ce ne te rappelle rien ?!
Donc quand on passe de k=16000 à k=32000, on double le nombre k de variables, et l'écart-type est multiplié par un facteur \( \sqrt 2 \) ... le pire, c'est que tu le sais...

Bizarre qu'un même code donne deux résultats différents. As-tu un moyen pour nous laisser télécharger ton fichier de session ?

Et quant à nos 5 simulations (C++, python pour Yoshi ; maple, javascript, C pour moi) qui donnent des résultats de moyenne d'emq conformes à la valeur théorique \( (n.p.(1-p))^{0.5} \), tu en penses quoi ?

Visiblement, les sessions MAPLE, et javascript te laissent de marbre.
Pour 32000 tirages : http://leon1789.perso.sfr.fr/tmp/Copie% … logic.html ... écart-type autour de 43 en moyenne ...
C'est logique car la formule de la loi binomiale indique (32000.p.(1-p))^0.5 avec p=1/16 , ce qui donne 43.3

Mais dans notre cas, on ne change pas le nombres d'observations : ce nombre est toujours de 100 ! Tu ne l'as pas modifié, hein ?

Ce que l'on change, c'est le nombre de tirages pour obtenir les écart-types à observer : 16000 ou 12000 ou 32000 tirages.  Et là, plus on augmente le nombre de tirages, plus les écart-types augmentent (tout comme la moyenne bien évidemment : 16000/16 ou 12000/16 ou 32000/16).

Si je fais tourner ton code donné message #19, en remplaçant 16000 par 32000 ou 12000 (boucle "i"), tout en gardant 100 expériences (boucle "fois"), je vais obtenir cela ? C'est ce que tu prétends.

Ok, je vais le faire tourner en C

Ben oui, si tu avances de 32000 pas aléatoires avant-arrière, tu arrives en générale plus loin (soit en avant, soit en arrière) du point de départ qu'avec 16000 pas. C'est des probas élémentaires.

Le problème est de comprendre comment on peut obtenir des écart-types de 25 car ce n'est pas une valeur normale pour cette expérience.

Justement, la loi binomiale est la loi exacte de l'expérience : quand on compte le nombre de fois qu'on a obtenu i (entier entre 0 et 15), on fait la somme de 16000 variables qui suivent la loi de Bernoulli (de paramètre 1/16) : c'est pour cela que je parle de la loi binomiale ayant pour paramètre n=16000 et p=1/16.
C'est la loi normale qui la forme simplifiée (c'est justement les premières versions du TCL).

Ok, je vais regarder cela en C, car ces moyennes proches de 25 sont étranges : elles montrent une anomalie, comme tu dis (car la théorie, Maple, javascript, Python, donnent des valeurs entre 29 et 31...)

oui, nous sommes d'accord.

Disons qu'entre 29 et 31, ça colle à la valeur théorique, donc rien de surprenant. Alors que 25, c'est loin de la valeur théorique, donc là, c'est étrange.
Est-ce que tu peux vérifier encore une fois que ton source C produit bien 100 écart-types dont la moyenne est grosso-modo 25 , s'il te plait ?

ok, je vais ajouter cela.

Merci d'avoir expliciter ton code. J'ai pu ainsi le placer dans un source javascript pour que l'on puisse l'exécuter facilement, simplement en chargeant cette page web : http://leon1789.perso.sfr.fr/tmp/simult … logic.html

Le code de la page est la traduction "mot pour mot" du tien, avec en plus le calcul de la moyenne des écart-types obtenus (ce que tu fais dans ton module annexe).

Pour exécuter le script, il suffit de charger la page et il y a exécution automatique. On recharge la page, il y a ré-exécution, etc. Tu peux le faire sans risque.

On voit très bien que les valeurs des moyennes sur 100 écart-types tournent autour de 30...
Qu'en penses-tu ?

Pour mémoire, et preuve que je ne triche pas, voici le code de la page web (traduction "mot à mot" de ton code C, à partir de <script>) :

Ok, tu expliques que la valeur 25 viendrait de nombreuses observations. En C je suppose, ça me va.
Personnellement, quand je fais de nombreuses (bien sûr une seule ne suffit pas) observations, en Maple par exemple, c'est plutôt la valeur 31 qui vient.

A la place de faire des sciences expérimentales, on peut faire des mathématiques (théorie des probabilités) pour calculer directement la valeur exacte théorique de l'écart-type.  Ce n'est pas compliqué, car les variables que tu étudies dans ton documents suivent une loi binomiale B(n,p) (qui est proche d'une loi normale, ok) où n = 16000 et p = 1/16 .  Or, et c'est marqué dans tous les bouquins et cite web, l'écart-type de la loi binomiale B(n,p) est \( \sqrt{np(1-p)} \), ce qui donne dans notre cas précis la valeur \( \frac{25}{2} \sqrt 6 \), soit environ 30.6

Ainsi, la valeur 25 observées sur de nombreuses observations est assez étrange... Peux-tu refaire ces observations (en C, si c'est ce langage que tu as utilisé)

En ce qui concerne Scilab dans ton document : l'écart-type constaté est de 39.5 , ok . Mais cela ne repose que sur une seule observation, celle de ton document. Donc c'est trop juste pour conclure, non ?  Sur cette expérience, l'écart-type peut varier "facilement" de 20 à 42 sur différentes observations...

Qu'en penses-tu ?

Tu veux dire que la fonction que tu as testée n'est pas celle implémentée à ce jour dans Scilab ?