Jouons à Pile ou Face

Bonjour Dlzlogic,

1°) Encore une fois, vous répondez à côté de ma question. Pourtant, je ne m'exprime pas en chinois, il me semble ?
Ma question est : pourquoi quand vous produisez vos 0 et 1 en utilisant le modulo 2, utilisez vous le code

Code:

int r = rand()%2;
if (r < 1) r=0;
else r=1;

plutôt que tout simplement

Code:

int r = rand()%2;


Ça ne change a priori rien au résultat, mais je trouve ça curieux ...

2°) Le fait de tirer les entiers entre 0 et 127 avec 7 "pile ou face" plutôt que de les tirer simplement avec rand()%128 n'a rien à voir avec le théorème central limite. Le fait d'avoir une distribution à très peu près normale (pour l'illustration de "à très peu près", voir mes comparaisons binomiale-normale plus haut) vient du fait qu'on fait 100 000 tirages, peu importe comment du moment que les tirages sont indépendants et que les 128 entiers sont équiprobables.

3°)

8- il est comique de supposer que le générateur de Borland est veux et obsolète.

Vraiment ? Votre simulation a mis en évidence un bug, vous l'avez vous-même constaté. Le bug ne se trouve pas dans le code. Conclusion logique : le bug se trouve dans le générateur, et ce générateur est donc non fiable et obsolète (les générateurs actuels n'ont pas ce défaut).
Auriez vous une autre interprétation du bug que vous avez constaté ?

Le code que j'ai copié date de quelques mois, qu'il vous plaise ou non n'a aucune importance.
Pour vérifier les explication de cet article, je n'avais pas d'autre moyen que de tester. Je connais votre méthode : vous savez, donc pas besoin d'essayer quoi que ce soit. Autre hypothèse, vous ignorez qu'il y a deux lignes en commentaire.
Autre information, sauf en cryptographie, les générateur sont utilisés pour des tests ou du graphisme. Si mon générateur est jugé vieux et/ou obsolète, il faudrait au moins des arguments, or je ne connais pas de test publié et reconnus.
Vous m'avez proposé de m'expliquer le TCL et "variable aléatoire", j'ai accepté.

C'est marrant, vous vous écrivez souvent des trucs du genre "Encore une fois, vous répondez à côté de ma question.".
D'abord c'est parfaitement impoli et, comme ce n'est pas vrai, je me pose la question.
- c'est votre façon de relancer le débat,
- c'est une manière de vous affirmer
- vous n'avez pas compris ma réponse
- c'est une figure de style pour laisser entendre que je suis de mauvaise foi ou que je ne ne comprends rien,
Liste non limitative, mais c'est à mon tour de dire que vous ne répondez jamais à mes question, mais si je le constate et que je ne le signale pas, c'est parce que je suis poli.

Bonhour,
Suite à votre demande, j'ai refait les simulations avec 10 000 nombres au lieu de 100 000.

Code:

10 000 Nombres crés par Pile ou fce calculé avec %100
Nombre = 128  Moyenne = 78.12  emq=9.94  ep=6.63
Médiane = 65.00 Min = 54.00  Max 109.00
    Rapport EMQ/EMA = 1.26  théorique 1.25

10 000 Nombres version de base calculés avec %128
Nombre = 128  Moyenne = 78.12  emq=8.75  ep=5.83
Médiane = 78.00 Min = 56.00  Max 99.00
    Rapport EMQ/EMA = 1.26  théorique 1.25

10 000 Nombres crés par Pile ou fce calculé avec %2
Nombre = 128  Moyenne = 78.12  emq=8.98  ep=5.99
Médiane = 81.50 Min = 57.00  Max 100.00
    Rapport EMQ/EMA = 1.22  théorique 1.25

10 000 Nombres version de base calculés avec %128
Nombre = 128  Moyenne = 78.12  emq=8.58  ep=5.72
Médiane = 79.00 Min = 56.00  Max 101.00
    Rapport EMQ/EMA = 1.25  théorique 1.25
 

C'est curieux que vous vous focalisiez sur une histoire de compilateur, de comparaison avec de résultat d'une formule, bref de choses d'importance mineure, alors que vous oubliez ou ignorez les notions fondamentales.

Vous m'avez posé la question de savoir pourquoi j'utilisais de tirage à pile ou face pour former des nombres afin de vérifier la validité de la loi normale.
Je l'ai déjà dit, mais je me répète : j'ai lu dans nom cours que la normalité de la répartition des écarts à la moyenne avait été vérifiée entre autre avec le tirage à pile ou face, j'ai fini par comprendre comment et au moins, cette méthode était incontestable, comme ne l'a pas été celle du tir au canon, contestée par Gbzm et sa disciple.

Merci pour avoir fait le test avec 10 000 tirages d'entiers entre 0 et 127.  Comme le problème est effectivement lié à l'installation utilisée, en l'occurrence le générateur de nombres pseudo-aléatoires utilisé, il est important que ces tests soient faits sur votre installation.
Dans le cas de 10 000 tirages, le nombre d'occurrences d'un entier donné suit une loi binomiale de paramètres 10 000 et 1/128, dont l'écart-type est 8.80... Les résultats expérimentaux que vous trouvez sont 9.94, 8.75, 8.98, 8.58. Aucune incohérence flagrante avec le 8.84 théorique.
Par contre, comme vous l'avez constaté dans le cas de 100 000 tirages il y a incohérence. Dans ce cas,  le nombre d'occurrences d'un entier donné suit une loi binomiale de paramètres 100 000 et 1/128, dont l'écart-type est 27.84... Or, quand vous faites la simulation en tirant les 0 et 1 avec rand()%2, vous trouvez un écart-type de 16.72. J'ai relevé cette anomalie dès que vous avez publié votre simulation.

Dlzlogic a écrit:Si mon générateur est jugé vieux et/ou obsolète, il faudrait au moins des arguments, or je ne connais pas de test publié et reconnus.

Vous avez vous-même fait le test et fourni un argument imparable : l'écart-type de 16.72 prouve que le rand()%2 de votre générateur ne fournit pas, comme il le devrait s'il était de bonne qualité, la simulation d'une suite de variables de Bernoulli indépendantes de paramètre 1/2. Bien sûr, ce test serait encore plus convaincant encore s'il était répété, disons, une vingtaine de fois, en donnant à chaque fois un écart-type qui est moins des 2/3 de la valeur théorique.
Le défaut est flagrant sur la longue suite (700 000 tirages), il n'apparaît pas sur la suite plus courte (70 000) que vous avez bien voulu tester à ma demande. Je suspecte donc un problème de période trop courte pour le bit de poids faible (celui qui donne le modulo 2), mais je ne suis pas sûr de cette explication.
C'est pour cela que je serais intéressé par la lecture de l'article que vous avez mentionné. Je vous en ai déjà demandé la référence. Pourriez-vous me la donner ? Merci.

Bonjour,
J'ai lu cet article il y a des année, je n'ai aucun moyen de le retrouver.
Mais il me semble bien que le petit paragraphe en anglais que vous avez cité parle justement de ce problème.
D'ailleurs, mon générateur a souvent été décrié sans aucun argument. Y'aurait peut-être un signe de la philosophie des membres de forums. Je ne me pense pas trop me tromper en disant qu'à part la cryptographie, les générateurs de nombres aléatoires ne servent qu'aux simulations pour expériences.

PS le test avec 10000 nombres et mod(2) est non satisfaisant le rapport emq/ema n'est pas bon.

" Bien sûr, ce test serait encore plus convaincant encore s'il était répété, disons, une vingtaine de fois, en donnant à chaque fois un écart-type qui est moins des 2/3 de la valeur théorique."

Chiche Pierre?

Voilà :

Code:

10 000 Nombres crés par Pile ou fce calculé avec %2
Nombre = 128  Moyenne = 78.12  emq=8.90  ep=5.93
Médiane = 80.50 Min = 56.00  Max 97.00
    Rapport EMQ/EMA = 1.23  théorique 1.25

10 000 Nombres crés par Pile ou fce calculé avec %2
Nombre = 128  Moyenne = 78.12  emq=8.57  ep=5.72
Médiane = 80.00 Min = 57.00  Max 103.00
    Rapport EMQ/EMA = 1.26  théorique 1.25

10 000 Nombres crés par Pile ou fce calculé avec %2
Nombre = 128  Moyenne = 78.12  emq=8.35  ep=5.57
Médiane = 81.50 Min = 57.00  Max 104.00
    Rapport EMQ/EMA = 1.25  théorique 1.25

10 000 Nombres crés par Pile ou fce calculé avec %2
Nombre = 128  Moyenne = 78.12  emq=8.23  ep=5.49
Médiane = 79.50 Min = 62.00  Max 106.00
    Rapport EMQ/EMA = 1.23  théorique 1.25

10 000 Nombres crés par Pile ou fce calculé avec %2
Nombre = 128  Moyenne = 78.12  emq=8.25  ep=5.50
Médiane = 76.00 Min = 61.00  Max 98.00
    Rapport EMQ/EMA = 1.28  théorique 1.25

10 000 Nombres crés par Pile ou fce calculé avec %2
Nombre = 128  Moyenne = 78.12  emq=9.40  ep=6.27
Médiane = 79.50 Min = 54.00  Max 102.00
    Rapport EMQ/EMA = 1.25  théorique 1.25

10 000 Nombres crés par Pile ou fce calculé avec %2
Nombre = 128  Moyenne = 78.12  emq=8.09  ep=5.40
Médiane = 76.50 Min = 53.00  Max 98.00
    Rapport EMQ/EMA = 1.22  théorique 1.25

10 000 Nombres crés par Pile ou fce calculé avec %2
Nombre = 128  Moyenne = 78.12  emq=8.82  ep=5.88
Médiane = 72.50 Min = 60.00  Max 107.00
    Rapport EMQ/EMA = 1.26  théorique 1.25



Je ne sais pas combien il y en a.
Quelles sont vos conclusions.
J'aimerais bien avoir aussi l'avis de Beagle et le même type de simulation avec son compilateur.

D'ailleurs, mon générateur a souvent été décrié sans aucun argument.

Mais vous avez vous-même donné un argument frappant ! Vous avez montré que votre simulation avec le rand()%2 sur 100 000 tirages donne un écart-type de 16.72 très loin du 27.84 théorique. Ce 27.84 est en accord avec les autres simulations que vous avez pu faire utilisant rand()%100 ou en tirant directement les entiers entre 0 et 127, en accord aussi avec les simulations faites de mon côté.
Cela fait quatre ou cinq fois que je vous écris cela. Vous n'imprimez pas ?

Pour ce qui est du test à répéter, c'est bien entendu ce test avec 100 000 tirages (je sais, c'est 10 fois plus long). En effet, c'est celui-ci qui montre que le générateur que vous utilisez n'est pas fiable.

Bon, je pensais avoir été clair.
Cette anomalie que vous appelez bug, lorsqu'on fait mod(2) est absolument générale et ne concerne en aucun cas, particulièrement le rand de chez Borland.
Oui, j'aurais dû imprimer dans ma tête que je ne devais pas me poser de question et me souvenir que mod(2) devait être évité surtout quand les résultats seraient examinés par vous ou par Beagle.
Comme je vous l'ai dit plusieurs fois, ce module était un test, j'aurais dû faire attention en l'utilisant, surtout j'aurais dû me douter que vous l'examineriez à la loupe pour détourner le fil de son sujet d'origine qui était de vérifier les deux théorèmes de Bernoulli.

Etes-vous sûr que le rand de votre compilateur n'a pas la même anomalie ? L'avez -vous testé ? Je me souviens que le module de calcul de Python était un peu bizarre. Peut-être pour éviter cette anomalie, je ne sais pas.

Par ailleurs, si vous connaissez un outil de test de qualité des générateurs de nombres aléatoires, c'est le moment de me donner un lien, sinon, ce problème mineur ne mérite pas qu'on en fasse tout un plat.

PS. Oui, j'ai fait suffisamment d'essais pour vérifier cette "anomalie", et vous l'avez-vous fait ? quelles conséquences ?

Je ne suis pas familier de C++, mais j'ai essayé :

Code:

// testDlz
#include <stdio.h>
#include <cmath>
#include <stdlib.h>
#include <time.h>

int main() {
  srand(time(0));
  for (int k=0; k<20; k++)
  {
 
      int Res128[128];
      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()%2;
          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]++;
      }
      int S1=0;
      int S2=0;
      for (int i=0; i<128; i++)
      {
         S1+=Res128[i];
         S2+=(Res128[i]*Res128[i]);
      }
      float M=S1/128;
      float V=S2/128-M*M;
      float EcTy=sqrt(V);
      printf("Ecart-type : %f\n",EcTy);
  }
}

et ça donne :
Ecart-type : 35.693138
Ecart-type : 34.899857
Ecart-type : 35.355339
Ecart-type : 33.361656
Ecart-type : 33.421551
Ecart-type : 35.440090
Ecart-type : 33.704597
Ecart-type : 35.128338
Ecart-type : 35.199432
Ecart-type : 35.608986
Ecart-type : 34.292858
Ecart-type : 34.176014
Ecart-type : 34.871193
Ecart-type : 33.615471
Ecart-type : 33.256577
Ecart-type : 32.634338
Ecart-type : 33.645206
Ecart-type : 33.045422
Ecart-type : 33.926392
Ecart-type : 35.425980
Une anomalie encore, mais dans l'autre sens : écart-type trop élevé !

Python est raisonnable :

Code:

import random as rd
import numpy as np

def tirage() :
    return sum(rd.randrange(2)*2**i for i in range(7))

def scoresPF() :
    liste = np.zeros(128)
    for _ in range(100000) :
        liste[tirage()] += 1
    return liste

print([round(np.std(scoresPF()),2) for _ in range(20)])

donne les écarts-types
[26.99, 29.51, 29.24, 29.5, 26.64, 28.49, 27.76, 25.48, 27.32, 28.08, 28.25, 27.77, 29.23, 26.49, 29.36, 26.34, 27.12, 26.56, 26.79, 24.43]

Ah, je me suis laissé piéger par la syntaxe C++ et les problèmes entiers/flottants pour la division ! Une petite correction sur le code :

Code:

#include <cmath>
#include <stdlib.h>
#include <time.h>

int main() {
   srand(time(0));
   for (int k=0; k<20; k++)
   {
  
      int Res128[128];
      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()%2;
         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]++;
      }
      int S1=0;
      int S2=0;
      for (int i=0; i<128; i++)
      {
         S1+=Res128[i];
         S2+=(Res128[i]*Res128[i]);
      }
      float M=S1/128.;
      float V=(S2/128.)-M*M;
      float EcTy=sqrt(V);
      printf("Moyenne : %f\n",M);
      printf("Ecart-type : %f\n",EcTy);
   }
}

et tout rentre dans l'ordre :
Moyenne : 781.250000
Ecart-type : 26.128588
Moyenne : 781.250000
Ecart-type : 30.724836
Moyenne : 781.250000
Ecart-type : 26.058228
Moyenne : 781.250000
Ecart-type : 27.371004
Moyenne : 781.250000
Ecart-type : 28.832491
Moyenne : 781.250000
Ecart-type : 27.006943
Moyenne : 781.250000
Ecart-type : 26.944387
Moyenne : 781.250000
Ecart-type : 25.725718
Moyenne : 781.250000
Ecart-type : 22.935030
Moyenne : 781.250000
Ecart-type : 26.931335
Moyenne : 781.250000
Ecart-type : 26.638494
Moyenne : 781.250000
Ecart-type : 27.488918
Moyenne : 781.250000
Ecart-type : 27.202366
Moyenne : 781.250000
Ecart-type : 26.918859
Moyenne : 781.250000
Ecart-type : 27.474705
Moyenne : 781.250000
Ecart-type : 27.099354
Moyenne : 781.250000
Ecart-type : 27.190014
Moyenne : 781.250000
Ecart-type : 25.036224
Moyenne : 781.250000
Ecart-type : 27.726624
Moyenne : 781.250000
Ecart-type : 24.819977

Résultat donforme à celui de python, et conforme à la valeur théorique 27.84 pour l'écart-type de la distribution du nombre d'occurrences..
Morale : c'est vraiment votre générateur de nombres pseudo-aléatoires qui est fautif.

Et alors, quel est le problème ?
C'est ça qui me rend hérétique, ignorant ou je ne sais quoi ?
C'est typiquement une diversion du sujet initial.

Bon, j'avoue, la théorie des probabilités basée sur les deux théorèmes de Bernoulli, c'est complètement du bidon. La seule théorie valable est celle issue des axiomes de Kolmogorov. En fait tout est parfait sauf que cette théorie ne mène à rien et il a toujours été impossible de citer un exemple que l'on puisse analyser.
Bon, tout compte fait, vous êtes un champions, vous avez réussi à générer des tas de messages inutiles, votre application à ridiculiser les gens est tout à fait au point, ce qui est est dommage est que vous réussissiez à entrainer dans votre critique fondamentale des braves gens comme beagle.

Pour conclure si vous réussissez à justifier l'analyse des générateurs sans test extérieur et labellisé, je laisserai vos messages, sinon suppressions. Je tiens à ce que mon forum garde une certaine rigueur et une certaine tenue.

Il est certain que vos interventions sont particulièrement désagréables et parfaitement inutiles.
Vous avez observé que le problèmes des générateurs n'était pas simple, mais, sauf utilisation spéciale et critique, type cryptographie, les génerateurs ne sont utilisés que pour des simulations sans grande importance.
Vous avez profité d'un test personnel et d'une distraction de ma part, puisque j'ai utilisé un cas de calcul que je savais peu précis.
Je considère que si vous voulez continuer à écrire sur ce forum, il faudra sérieusement surveiller ce que vous écrivez.
Je pense que la technique je vais employer sera de supprimer vos messages que je jugerai négatifs ou non souhaitables. Alors faites comme Léon, préservez une copie, puis remettez là à la lecture, là ma réaction sera plus claire.

Bon, j'ai lu votre code, vous devriez justifier ces deux lignes :

Code:

      float M=S1/128.;
      float V=(S2/128.)-M*M;


Vous appliquez la formule de Koênig Elle n'est valable qu'en théorie.
Donc zéro pour la simulation.
Il est vrai que le nombre de variables est grand, mais vous devriez justifier les hypothèses que vous utilisez cette formule pour cette formule..
Oui, je connais sa démonstration, relisez là et on pourra discuter.
Je sais bien que de ma part, c'est parfaitement mesquin, mais j'essaye de me mettre à votre niveau.

Dlzlogic a écrit:Je sais bien que de ma part, c'est parfaitement mesquin,

Je ne vous le fais pas dire.

Pourquoi prenez-vous cette démonstration de la faille du générateur que vous utilisez pour une attaque personnelle. ?
C'est grâce à votre test que cette faille est apparue (même si, d'après ce que je comprends, elle était déjà signalée dans l'article que vous avez lu et que vous ne retrouvez pas).
Ce n'est pas vous qui avez écrit ce générateur, vous n'en êtes pas responsable. Retrouvez donc votre calme, s'il vous plait.

Bonne nuit.

Oh, c'est vraiment marrant. Maintenant je suis sûr que vous n'avez aucune idée de la façon dont sont écrits les générateurs, pourtant, j'ai été très clair dans mes explications.
Le problème important et que probablement vous n'avez pas capté, c'est que la mise en cause d'un générateur, le mien en l'occurrence, démonte par définition toute argumentation de ma part.
En droit, cela se dit "le possessoire tient le pétitoire" en matière "scientifique" une simple faute de virgule annule toute une argumentation.
Vous êtes vraiment des champions.
Pour mémoire, je vous prie de bien vouloir donner un lien sur le module de calcul de votre générateur.
Je sais trouver ce module chez Python, et vous ?
D'ailleurs je ne suis pas sûr du tout que vous ayez la moindre idée de ce qu'est l'aléatoire, cf la corde de Bertrand.

Bonjour Humx3,
Là, ce n'est pas de la mesquinerie, c'est juste que j'ai observé que vous ne connaissiez pas la définition de l'écart-type et de son mode de calcul.
C'est tout de même très étonnant de la part d'un professeur de maths et qui a peut-être enseigné les probabilités.
On trouve de tout sur les forums.

Bonsoir Dlzlogic,

votre application à ridiculiser les gens est tout à fait au point,

Je ne cherche pas à vous ridiculisez. Mais vous y réussissez fort bien tout seul dans vos derniers messages.
Je cherche ici à expliquer quelque chose de très simple et très clair.
Vous tirez 100 000 fois des nombres entre 0 et 127 et vous notez les occurrences de chaque nombre. Les nombres d'occurrences sont des variables aléatoires de loi binomiale de paramètres 100 000 et 1/128. Vu le 100 000, c'est pratiquement indistinguable d'une loi normale, pas de problème de ce côté.
Le problème est que quand vous faites la simulation en tirant l'écriture binaire des nombres avec rand()%2, vous trouvez un écart-type de 16,72, très loin de l'écart-type de la loi binomiale de paramètres 100 000 et 1/128 qui est 27,84. Par contre, quand vous faites la simulation en tirant directement les nombres entre 0 et 127, ou en tirant leur écriture binaire avec un rand()%100, quand je la fais en python, quand je la fais en C++ avec rand()%2 du générateur de mon C++, l'écart-type trouvé est toujours cohérent avec ce 27,84.
Conclusion, claire comme l'eau de roche : il y a un problème avec le rand()%2 (autrement dit, le bit de poids le plus faible) du générateur de nombres pseudo-aléatoires dans votre installation.
Quelle difficulté avez-vous à reconnaître cette évidence ?

Vous vouliez voir des explications sur les variables aléatoires et le TCL dans la situation des 100 000 tirages d'entiers entre 0 et 127. Le voulez-vous toujours ? Vous avez déjà eu une foultitude d'explications dont vous n'avez jamais tiré profit. Pour varier, je peux le faire en m'inspirant du théorème 3 du manuel d'Oliver Garet.

Pierre je te remercie de ne pas fermer et effacer ce fil de discussion.
Cela n'enlève rien à tes propos sur l'ubiquité de la loi normale, sujet où tu pourrais avoir raison,
si tu le formulais de façons moins extrème.
J'aimerais bien un dessin du théorème 3 du livre d'Aléa si GBZM s'en sent.

Bonsoir Beagle,
Je me suis rendu compte que Humx3 ne connaissait pas la définition de l'écart-type. C'est tout de même assez énorme. Il ne sait pas non plus que, qui dit écart-type dit "écart moyen quadratique d'une expérience aléatoire de même loi", c'est à dire dont le résultat est conforme à la répartition normale, fondement de la théorie des probabilités.

Je ne sais pas si tu as des accords cachés avec Humx3, mais il faut savoir qu'il n'y connait rien en la matière et que c'est un très mauvais conseil.
Une preuve simple, il est incapable de citer et encore moins justifier un exemple simple d'application de ce qu'il considère comme LA Théorie des probabilités.

Ah le théorème 3 du livre d'Aléa ! Il est impossible de produire une série uniforme comme le prétend ce fameux théorème.
Il me semble que l'exploitation du fichier des températures et de n'importe quel autre fichier de quoi que ce soit me parait une preuve irréfutable.
Mais je suppose que ton ami Humx3 trouvera un motif de me contredire, comme d'habitude.

Bon dimanche, et surtout allez voter !

Dlzlogic continue sa diversion ridicule sur l'écart-type. Juste une question : la statistique des occurrences porte-t-elle sur la totalité de la population des 128 entiers de 0 à 127, ou seulement sur un échantillon ?

Par contre, Dlzlogic n'explique toujours pas pourquoi il refuse de voir le phénomène qui crève les yeux et qu'il a lui-même mis en évidence.

Illustrer le fameux théorème 3 ? Pourquoi pas ? Est-ce que ça sera parlant, on verra. Voir https://dlz9.forumactif.com/t2131p25-le-theoreme-3-du-livre-d-olivier-garet#25421

Voir https://dlz9.forumactif.com/t2131p25-le-theoreme-3-du-livre-d-olivier-garet#25422

Bonjour,

Humx3 a écrit:Dlzlogic continue sa diversion ridicule sur l'écart-type. Juste une question : la statistique des occurrences porte-t-elle sur la totalité de la population des 128 entiers de 0 à 127, ou seulement sur un échantillon ?

Beagle m'a recommandé d'être gentil avec vous.
D'abord il me semble que c'est vous qui avez parlé de l'écart-type, oui, c'était une diversion de votre part, alors répondez à ces deux questions :
Quelle est la définition de l'écart-type, donc la formule permettant de le calculer ?
Vous avez donné une valeur théorique de cet écart-type, suivant le nombre de valeurs étudiées, pouvez-vous justifier ces deux valeurs ?

Votre question sur la statistique des occurrences est étonnante. On a une liste de nombres de 0 et 127. Tous ces nombres sont pris en compte.