Probabilité/Statistique : Convergence vers e ?

[Axiom]

Bonjour à tous,

Depuis quelque temps, je dépile certains problèmes mathématiques que j'avais entreposés dans mon PC.
Parmi eux, en voici un qui me donne du fil à retordre que j'avais trouvé à l'époque sur un autre forum et qui, peut-être, en intéressera certain.e.s.

La question globale était de déterminer le nombre moyen de tirages à effectuer de nombres entre [0,1[ (qui suivent une loi uniforme continue) pour que la somme dépasse 1. Et il semblait que ce nombre tendait vers (c'est à vérifier !!!).

L'énoncé peut -être globalement formalisé de la manière suivante :

Soit où est un échantillon i.i.d. issu de la loi uniforme continue .
On note , où est le plus petit entier tel que .

La question est alors de déterminer .

J'ai fait un algo en Java pour ceux qui veulent tester :

Code: Tout sélectionner

public static void prog(int P) {
      
      int [] N = new int [P];
      for(int i = 0; i < P; i++ ) {
         double S_i = 0;
         while(S_i < 1) {
            S_i += Math.random();
            N[i]++;
         }
      }

      // Pour la moyenne et écart-type
      double mean = 0.0;
      double sd = 0.0;
      for(int N_i : N) {
         mean += N_i;
      }
      mean /= P;
      for(int N_i : N) {
         sd += Math.pow(N_i- mean, 2);
      }
      sd /= (P-1);
      sd = Math.sqrt(sd);
      
      System.out.println("mean = "+mean+"\nsd = "+sd);
   }

À vrai dire, je ne sais pas trop comment m'y prendre... J'avais pensé à essayer de discrétiser la loi en fixant le nombre de chiffres après la virgule des variables aléatoires et voir ce qui se passe, mais je ne sais pas si c'est très rigoureux...
Bref, si quelqu'un à des idées...

[Ben314]

Salut

On note , où est le plus petit entier tel que .

Déjà, ta "modélisation" n'a aucun sens :
Quand on parle du "plus petit entier tel que", ben faudrait peut-être lui donner un nom à ton entier pour qu'il corresponde à quelque chose dans la formule qui suit.
Tu pourrait me rétorquer que c'est "sous entendu" que c'est évidement que c'est de dont tu parle, mais ça serait très nettement mieux en l'écrivant vu que ça te ferait en particulier comprendre que ce "plus petit entier i tel que . . .", ben c'est évidement pas un truc qui dépend de , mais qui ne dépend de rien du tout (ou plutôt, comme toute V.A.R. qui dépend uniquement du de l'univers des tirages).

Bon, sinon, la proba que la somme dépasse lors du -ième tirage, c'est la mesure -dimensionnelle de l'ensemble .
Si un peu plus généralement, pour on note la mesure -dimensionnelle de l'ensemble

Alors on a bien sûr puis on vérifie facilement que et que
ce qui permet de montrer relativement facilement que et donc que

[LB2]

Bonjour,

en le reformulant, si N est la variable aléatoire valant le nombre de tirages nécessaires pour que la somme dépasse 1, on a N(Omega)=N\{0,1} et pour n entier supérieur égal à 2, la loi de N donnée par



On sait que la variable aléatoire admet pour densité la convoluée d'ordre n-1 de la densité d'une uniforme sur [0,1], les étant indépendantes. On dit que suit la loi d'Irwin-Hall et en particulier on sait que pour

ce qui nous donne après calcul de l'intégrale le même résultat que Ben :

Pour obtenir le nombre moyen de tirages à effectuer pour que la somme dépasse 1, il suffit de calculer l'espérance de la variable aléatoire discrète . Comme on connait désormais sa loi, rien de plus facile et on trouve

[pascal16]

Code: Tout sélectionner

int [] N = new int [P];
double S= 0;
 for(int i = 0; i < P; i++ ) {
      S= 0;
      while(S < 1) {
         S += Math.random();
         N[i]++;
     }
 }

tu obtiens bien un vecteur de P entiers te donnant une série statistique de ce que tu cherches
NB :
- "N[i]++" l'accès à un tableau pour est moins rapide qu'une variable locale, mais ça marche.
- double S= 0 à l'intérieur de la boucle for crée bcp de variables, on l’utilise si on met les boucles en parallèle (pas utile ici car l'accès en parallèle à un tableau va être problématique).
- sd /= (double)(P-1) : te donne l'estimateur de l'écart-type, ce qui est bien ici
- pour moyenne, il me semble que la fonction existe, ou tout du moins somme qui te fais la somme des entiers, puis divise par P avec un cast pour que ça se fasse avec des réels, pas des entiers.

[Axiom]

Bonjour à tous et merci pour vos réponses.

Ben, merci pour tes remarques. En fait, je vais rien rétorquer parce que c'était pas de dont je voulais parler. En fait, j'avais mis au départ parce que je voulais signifier que c'était le plus petit entier, relativement à l'échantillon . Mais en effet, c'était sans doute maladroit, voire incohérent car ça ne dépend de rien du tout, si ce n'est de comme tu le fais justement. Bref, je voyais pas trop comment le noter.

Merci aussi à LB2 pour ses explications claires, elles sont bien complémentaires de celles de Ben, et je comprends un peu mieux en effet les liens avec Irwin-Hall.

Enfin Pascal, merci pour la relecture de code, c'est vrai que c'était pas très optimisé (surtout la variable dans la boucle). ^^'
Je pense que l'on pourrait optimiser oui avec une variable locale ou même une structure de hachage pour un accès constant.
Normalement comme et sont initialisés comme des double, c'est pas utile de les caster, en tout cas l'algo retournait bien des double, mais c'est sans doute plus sûr et clair de les caster, je suis d'accord.

[pascal16]

pour la moyenne et l'écart-type, ici, on travaille avec des petits nombres, quand on travaille avec des grands nombres, il est très facile de saturer la valeur max de "int" avec soit une erreur de dépassement de capacité, soit des nombres négatifs.
Il faut alors soit passer par des double (avec division dans la boucle donc lent), soit par des boucles limitées(à 1 000 000 par ex), en lancer plusieurs et utiliser la moyenne des moyennes.
J'ai eu ce problème un jour en réutilisant une source qui avait à peine 2 ans mais qui donnait une valeur différente de celle attendue (moyenne négative heureusement facile à voir).