Le générateur aléatoire de Dlzlogic

Bon, tu ne te rends pas compte que tu utilises des arguments contre lesquels justement tu milites.
Il est indéniable que l'opération mod(2) est à éviter. Il suffit de s'en souvenir. C'était le but de mon test d'il y a quelques mois et que j'ai réutilisé bêtement, parce que j'ai oublié justement ce dont je devais me souvenir.

Je n'ai pas suivi ton match avec GBZM sur les modulos.

Si tes résultats suivent la théorie que tu dis connaitre, c'est toi qui a raison.
Mais sur ce qui est pointé par GBZM, il m'a semblé que tu bottais en touche pour ne pas avoir a en parler = refaire le test sur grand nombre.

Oui, tu as tout à fait raison, mais le niveau de nos discussion est très-très loin d'être à ce niveau là, puisque ça ce limite à "tu as tort", "résout ce calcul", "voilà un système qui matche pas" etc.

Pierre: "Bonjour Dattier,
D'abord, je ne pense pas qu'un générateur de nombre aléatoires puisse "dérailler".
...
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."

Ben un générateur qui retrouve une dispersion plus faible que la théorie est un générateur qui déraille

Perso mon générateur de pile ou face alterne les 0 et 1
01010101010101
il est super moins dispersible que beaucoup d'autres

@ Beagle Tu t'arrange avec qui tu veux.

Code:

10946 , 10914 , 11097 , 10948 , 10976 , 11064 , 11046 , 10776 , 10970 , 10789 ,
10854 , 11161 , 11006 , 11023 , 11012 , 11043 , 10889 , 10952 , 11203 , 11015 ,
10731 , 10881 , 10942 , 11116 , 10943 , 11152 , 10913 , 10962 , 11000 , 10906 ,
11025 , 10989 , 11031 , 10669 , 10986 , 10892 , 10778 , 10784 , 11059 , 10858 ,
11035 , 10954 , 11066 , 10900 , 10949 , 10927 , 11135 , 10682 , 11061 , 10750 ,
10720 , 10938 , 10967 , 10979 , 10908 , 10936 , 11013 , 10977 , 10866 , 11102 ,
10814 , 10855 , 10903 , 11040 , 10849 , 10928 , 10941 , 11071 , 11030 , 10945 ,
10910 , 11024 , 10943 , 10933 , 10982 , 11026 , 10818 , 10982 , 11041 , 10988 ,
10905 , 11134 , 11032 , 11032 , 11037 , 11007 , 11014 , 11048 , 11122 , 10838 ,
11023 , 11071 , 10866 , 10944 , 10992 , 11017 , 10869 , 10788 , 11119 , 10843 ,


Trois pile sur 10  mode %100
Nombre = 100  Moyenne = 10958.90  emq=107.79  ep=71.86
Médiane = 10829.00 Min = 10669.00  Max 11203.00
    Rapport EMQ/EMA = 1.26  théorique 1.25
Classe 1  nb=  1  1.00%     théorique 0.35%    |H
Classe 2  nb=  3  3.00%     théorique    2%    |HHH
Classe 3  nb=  7  7.00%     théorique    7%    |HHHHHHH
Classe 4  nb=  11  11.00%     théorique  16%    |HHHHHHHHHHH
Classe 5  nb=  26  26.00%     théorique  25%    |HHHHHHHHHHHHHHHHHHHHHHHHHH
Classe 6  nb=  26  26.00%     théorique  25%    |HHHHHHHHHHHHHHHHHHHHHHHHHH
Classe 7  nb=  18  18.00%     théorique  16%    |HHHHHHHHHHHHHHHHHH
Classe 8  nb=  7  7.00%     théorique    7%    |HHHHHHH
Classe 9  nb=  1  1.00%     théorique    2%    |H
Classe 10 nb=  0  0.00%     théorique 0.35%    |
 

Je viens à l'instant de passer à la version 2 de mon générateur.
C'est un sac de deux boules la 0 et la 1
On fait des tirages sans remises.
C'est pénible il faut le recharger un peu souvent, mais c'est mieux on ne sait pas si c'est 0 ou 1 enfin pas à chaque fois.
Si j'ai bien compris il aune période de 2.

Il est assez bon pour avoir de la faible dispersion je pense.

Bonsoir Dlzlogic,

Trois pile sur 10 mode %100

Conforme aux résultats théoriques : moyenne 10959 (espérance 11000), écart-type 108 (théorique 96).

Mais ce n'est pas cela qui va nous renseigner sur les problème du rand()%2 de votre installation !
Qu'est-ce qui vous empêche de faire la même simulation avec rand()%2 ?

Rien bien-sûr, mais dites moi une bonne raison pour laquelle je ferai ce que vous me demandez et pas la réciproque ? Vous vous prenez pour qui ?
11522 , 11509 , 11526 , 11520 , 11514 , 11528 , 11501 , 11523 , 11517 , 11504 ,
11509 , 11508 , 11510 , 11511 , 11542 , 11502 , 11508 , 11537 , 11502 , 11518 ,
11539 , 11499 , 11524 , 11521 , 11501 , 11529 , 11524 , 11504 , 11530 , 11515 ,
11523 , 11550 , 11498 , 11496 , 11521 , 11492 , 11521 , 11523 , 11518 , 11521 ,
11527 , 11507 , 11511 , 11520 , 11523 , 11517 , 11510 , 11515 , 11552 , 11491 ,
11521 , 11538 , 11481 , 11512 , 11503 , 11524 , 11513 , 11517 , 11515 , 11521 ,
11519 , 11502 , 11533 , 11522 , 11506 , 11550 , 11491 , 11504 , 11542 , 11502 ,
11531 , 11523 , 11527 , 11509 , 11534 , 11490 , 11520 , 11513 , 11491 , 11520 ,
11527 , 11514 , 11545 , 11500 , 11516 , 11519 , 11518 , 11523 , 11507 , 11527 ,
11516 , 11534 , 11495 , 11532 , 11509 , 11486 , 11509 , 11531 , 11495 , 11547 ,


Trois pile sur 10 mode %2
Nombre = 100 Moyenne = 11516.57 emq=14.83 ep=9.88
Médiane = 11529.50 Min = 11481.00 Max 11552.00
Rapport EMQ/EMA = 1.27 théorique 1.25
Classe 1 nb= 0 0.00% théorique 0.35% |
Classe 2 nb= 2 2.00% théorique 2% |HH
Classe 3 nb= 8 8.00% théorique 7% |HHHHHHHH
Classe 4 nb= 14 14.00% théorique 16% |HHHHHHHHHHHHHH
Classe 5 nb= 23 23.00% théorique 25% |HHHHHHHHHHHHHHHHHHHHHHH
Classe 6 nb= 30 30.00% théorique 25% |HHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
Classe 7 nb= 13 13.00% théorique 16% |HHHHHHHHHHHHH
Classe 8 nb= 6 6.00% théorique 7% |HHHHHH
Classe 9 nb= 4 4.00% théorique 2% |HHHH
Classe 10 nb= 0 0.00% théorique 0.35% |

Bonjour,
Merci pour cette expérience, dont le résultat est très clair :
Moyenne de l'échantillon 11517 à plus de 5 écart-types de l'espérance 11000, et dispersion hors norme : écart-type sur l'échantillon 15 au lieu du 96 théorique.

@ Humx3
Merci, je sais lire.
Vous avez insisté lourdement pour que je fasse cette simulation avec un très grand nombre d'épreuves.
C'est donc dans un but précis.
1- je vous ai demandé de donner des indications précises concernant VOTRE générateur ; pas de réponse
2- vous n'avez pas précisé le but de cette simulation. Vous faites des cachoteries ou tout simplement vous ne savez pas très bien ce que vous faites ?
3- maintenant que vous avez le résultat, quelle conclusion en tirez-vous ?
4- citez une utilisation précise de ce générateur qui comme tous les générateurs basés sur cette formule, présentent le même inconvénient.
etc.
Il est indispensable que vous répondiez.

@ Beagle,
Tu as très bien joué la mouche du coche sur ce sujet. Alors coupe tes ailes et prend tes responsabilités et agit auprès de Humx3 pour qu'il se repose sur terre.

@ Dattier,
Un générateur ne peut pas "bugger".
Il y a plusieurs points qu'il faut comprendre.
Le hasard correspond à des lois bien précises parfaitement définies, démontrées et vérifiées.
On a voulu pour diverses raisons simuler des listes de nombres. Quand j'en ai eu besoin vers les années 78, j'ai lu des valeurs trigonométriques.
La seule raison réellement valable de disposer d'un générateur qui n'ait pas les inconvénients du "pseudo" était de travailler avec des nombres énormes, d'où l'utilisation des nombres de Mersenne. Il se trouve que ceux sont ceux qui connaissent le moins ce qui concerne les générateurs qui sont le plus exigeants, c'est humain mais désagréable sur un forum.
Il se trouve que les générateurs de base, c'est à dire utilisant la formule bien connue, ne devraient pas utiliser %2 pour faire du pile ou face. Ben oui, je l'avais oublié.
Un certain Pivot s'est inscrit hier. Il fait partie des matheux qui se souviennent très bien de ce qui ne marche pas ou mal, exemple : son système linéaire complètement artificiel, et on est en droit de se demander s'ils connaissent des choses qui marchent.
Bon, je répète, Il n'y a pas de bug dans un générateur, simplement, il y a des limites d'utilisation et un point connu à ne pas oublier : "%2" à éviter.

Dlzlogic a écrit:1- je vous ai demandé de donner des indications précises concernant VOTRE générateur ; pas de réponse

Almost all module functions depend on the basic function random(), which generates a random float uniformly in the half-open range 0.0 <= X < 1.0. Python uses the Mersenne Twister as the core generator. It produces 53-bit precision floats and has a period of 2**19937-1. The underlying implementation in C is both fast and threadsafe. The Mersenne Twister is one of the most extensively tested random number generators in existence. However, being completely deterministic, it is not suitable for all purposes, and is completely unsuitable for cryptographic purposes.
See also
M. Matsumoto and T. Nishimura, “Mersenne Twister: A 623-dimensionally equidistributed uniform pseudorandom number generator”, ACM Transactions on Modeling and Computer Simulation Vol. 8, No. 1, January pp.3–30 1998.
Pour lire le papier :
http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/ARTICLES/mt.pdf
Dans cet article vous pouvez trouver un code C pour Mersenne Twister. J'en ai récupéré une autre version :

Code:

/*
   A C-program for MT19937, with initialization improved 2002/1/26.
   Coded by Takuji Nishimura and Makoto Matsumoto.

   Before using, initialize the state by using init_genrand(seed)  
   or init_by_array(init_key, key_length).

   Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura,
   All rights reserved.                          

   Redistribution and use in source and binary forms, with or without
   modification, are permitted provided that the following conditions
   are met:

     1. Redistributions of source code must retain the above copyright
        notice, this list of conditions and the following disclaimer.

     2. Redistributions in binary form must reproduce the above copyright
        notice, this list of conditions and the following disclaimer in the
        documentation and/or other materials provided with the distribution.

     3. The names of its contributors may not be used to endorse or promote
        products derived from this software without specific prior written
        permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR
   CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
   EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
   PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
   PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
   LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
   NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
   SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


   Any feedback is very welcome.
   http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html
   email: m-mat @ math.sci.hiroshima-u.ac.jp (remove space)
*/

#include <stdio.h>

/* Period parameters */  
#define N 624
#define M 397
#define MATRIX_A 0x9908b0dfUL   /* constant vector a */
#define UPPER_MASK 0x80000000UL /* most significant w-r bits */
#define LOWER_MASK 0x7fffffffUL /* least significant r bits */

static unsigned long mt[N]; /* the array for the state vector  */
static int mti=N+1; /* mti==N+1 means mt[N] is not initialized */

/* initializes mt[N] with a seed */
void init_genrand(unsigned long s)
{
    mt[0]= s & 0xffffffffUL;
    for (mti=1; mti<N; mti++) {
        mt[mti] =
       (1812433253UL * (mt[mti-1] ^ (mt[mti-1] >> 30)) + mti);
        /* See Knuth TAOCP Vol2. 3rd Ed. P.106 for multiplier. */
        /* In the previous versions, MSBs of the seed affect   */
        /* only MSBs of the array mt[].                        */
        /* 2002/01/09 modified by Makoto Matsumoto             */
        mt[mti] &= 0xffffffffUL;
        /* for >32 bit machines */
    }
}

/* initialize by an array with array-length */
/* init_key is the array for initializing keys */
/* key_length is its length */
/* slight change for C++, 2004/2/26 */
void init_by_array(unsigned long init_key[], int key_length)
{
    int i, j, k;
    init_genrand(19650218UL);
    i=1; j=0;
    k = (N>key_length ? N : key_length);
    for (; k; k--) {
        mt[i] = (mt[i] ^ ((mt[i-1] ^ (mt[i-1] >> 30)) * 1664525UL))
          + init_key[j] + j; /* non linear */
        mt[i] &= 0xffffffffUL; /* for WORDSIZE > 32 machines */
        i++; j++;
        if (i>=N) { mt[0] = mt[N-1]; i=1; }
        if (j>=key_length) j=0;
    }
    for (k=N-1; k; k--) {
        mt[i] = (mt[i] ^ ((mt[i-1] ^ (mt[i-1] >> 30)) * 1566083941UL))
          - i; /* non linear */
        mt[i] &= 0xffffffffUL; /* for WORDSIZE > 32 machines */
        i++;
        if (i>=N) { mt[0] = mt[N-1]; i=1; }
    }

    mt[0] = 0x80000000UL; /* MSB is 1; assuring non-zero initial array */
}

/* generates a random number on [0,0xffffffff]-interval */
unsigned long genrand_int32(void)
{
    unsigned long y;
    static unsigned long mag01[2]={0x0UL, MATRIX_A};
    /* mag01[x] = x * MATRIX_A  for x=0,1 */

    if (mti >= N) { /* generate N words at one time */
        int kk;

        if (mti == N+1)   /* if init_genrand() has not been called, */
            init_genrand(5489UL); /* a default initial seed is used */

        for (kk=0;kk<N-M;kk++) {
            y = (mt[kk]&UPPER_MASK)|(mt[kk+1]&LOWER_MASK);
            mt[kk] = mt[kk+M] ^ (y >> 1) ^ mag01[y & 0x1UL];
        }
        for (;kk<N-1;kk++) {
            y = (mt[kk]&UPPER_MASK)|(mt[kk+1]&LOWER_MASK);
            mt[kk] = mt[kk+(M-N)] ^ (y >> 1) ^ mag01[y & 0x1UL];
        }
        y = (mt[N-1]&UPPER_MASK)|(mt[0]&LOWER_MASK);
        mt[N-1] = mt[M-1] ^ (y >> 1) ^ mag01[y & 0x1UL];

        mti = 0;
    }
  
    y = mt[mti++];

    /* Tempering */
    y ^= (y >> 11);
    y ^= (y << 7) & 0x9d2c5680UL;
    y ^= (y << 15) & 0xefc60000UL;
    y ^= (y >> 18);

    return y;
}

/* generates a random number on [0,0x7fffffff]-interval */
long genrand_int31(void)
{
    return (long)(genrand_int32()>>1);
}

/* generates a random number on [0,1]-real-interval */
double genrand_real1(void)
{
    return genrand_int32()*(1.0/4294967295.0);
    /* divided by 2^32-1 */
}

/* generates a random number on [0,1)-real-interval */
double genrand_real2(void)
{
    return genrand_int32()*(1.0/4294967296.0);
    /* divided by 2^32 */
}

/* generates a random number on (0,1)-real-interval */
double genrand_real3(void)
{
    return (((double)genrand_int32()) + 0.5)*(1.0/4294967296.0);
    /* divided by 2^32 */
}

/* generates a random number on [0,1) with 53-bit resolution*/
double genrand_res53(void)
{
    unsigned long a=genrand_int32()>>5, b=genrand_int32()>>6;
    return(a*67108864.0+b)*(1.0/9007199254740992.0);
}
/* These real versions are due to Isaku Wada, 2002/01/09 added */

int main(void)
{
    int i;
    unsigned long init[4]={0x123, 0x234, 0x345, 0x456}, length=4;
    init_by_array(init, length);
    printf("1000 outputs of genrand_int32()\n");
    for (i=0; i<1000; i++) {
      printf("%10lu ", genrand_int32());
      if (i%5==4) printf("\n");
    }
    printf("\n1000 outputs of genrand_real2()\n");
    for (i=0; i<1000; i++) {
      printf("%10.8f ", genrand_real2());
      if (i%5==4) printf("\n");
    }
    return 0;
}

Vous pouvez vous même le récupérer sur cette page :
http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/MT2002/emt19937ar.html

Merci pour la "réponse" à la première question. On y voit du baratin mais pas de formule.

Un générateur de nombres pseudo aléatoires est plus ou moins bon.
Les deux expériences faites avec votre rand()%2 montrent sans contestation possible qu'il ne produit pas ce qu'il devrait produire : des suites de 0 et de 1 qui puissent être prises pour des réalisations d'une suite de 0 et 1 tirés indépendamment et de façon équiprobable.
Le générateur de base de Python (MersenneTwister) n'est sûrement pas parfait, mais il est exempt de ce défaut.

Je vous ai déjà expliqué ce qu'il m'intéresserait de comprendre : d'où vient le défaut constaté de rand()%2 sur votre installation ? Les simulations habituelles avec un générateur correct confirment toujours les résultats théoriques ; c'est bien, mais on s'en lasse. Avoir un générateur qui rend des résultats qui divergent fortement des résultats théoriques est beaucoup plus intéressant, cela pose le challenge du "pourquoi" ? Je n'ai pas de réponse toute faite. Si j'avais votre générateur sous la main, je ferai des expériences complémentaires. Mais vu votre comportement, je renonce à vous demander de faire ces expériences.

Dlzlogic a écrit:Merci pour la "réponse" à la première question. On y voit du baratin mais pas de formule.

Votre mauvaise foi est écoeurante. Je vous ai donné l'article qui décrit l'algorithme MersenneTwister et le code C du générateur.
Vous pouvez vous reporter au paragraphe 2.1 (Description of MT) de l'article que j'ai mis en lien, ou lire le code C.

Bonjour

Dlzlogic a écrit:Il est indéniable que l'opération mod(2) est à éviter. Il suffit de s'en souvenir.

Pour se souvenir, il vaut mieux comprendre pourquoi. Apprendre sans comprendre n'est pas satisfaisant, me disaient mes profs.
En fait, le mod 2 est parfaitement correct, quand le générateur d'entiers qui mouline en amont (entre 1 et a_max) est de bonne qualité.
Il y a aussi une autre manière simple de générer des 0 et 1 de manière uniforme, via une division (arrondir a / a_max)


Le code simplifié du générateur du logiciel que j'utilise :

Code:

r --->  (427419669081 * r ) mod 999999999989

999999999989 est un nombre premier
427419669081 est un générateur du groupe multiplicatif modulo 999999999989.
r est initialisé à une valeur quelconque, comprise entre 1 et 999999999988.
Alors la réitération simule un tirage sur l'intervalle entier 1...999999999988 suivant la loi uniforme, avec un cycle de longueur 999999999988 ~ 10^12

Dlzlogic a écrit: Il n'y a pas de bug dans un générateur, simplement, il y a des limites d'utilisation et un point connu à ne pas oublier : "%2" à éviter.

est-ce que vous avez utilisé ce générateur pour simuler votre rattrapage concernant une pièce (%2) ?
Cela pourrait peut-être expliquer que vous trouviez un léger avantage dans le concret (qui n'existe pas en théorie).

Pivot a écrit:est-ce que vous avez utilisé ce générateur pour simuler votre rattrapage concernant une pièce (%2) ?

Je ne me souviens pas avoir simulé le rattrapage. Ce n'est qu'une conséquence directe de la loi des grands nombres.
Mais c'était bien tenté.

Pouvez vous formuler précisément et clairement, sans baratin, ce qui est une conséquence directe de la loi des grands nombres ? Des nombres, des faits vérifiables, un code de simulation.
En parlant de code, avec-vous vu le code C du Mersenne Twister ?

Dlzlogic a écrit:

Pivot a écrit:est-ce que vous avez utilisé ce générateur pour simuler votre rattrapage concernant une pièce (%2) ?

Je ne me souviens pas avoir simulé le rattrapage. Ce n'est  qu'une conséquence directe de la loi des grands nombres.
Mais c'était bien tenté.

ah oui?
et le 2% il sort de la loi des grands nombres,
pas d'une ancienne simulation?
La mouche du beagle.

Dlzlogic a écrit:

Pivot a écrit:est-ce que vous avez utilisé ce générateur pour simuler votre rattrapage concernant une pièce (%2) ?

Je ne me souviens pas avoir simulé le rattrapage.

toujours aussi surprenant. +++

HumHumHum a écrit:Pouvez vous formuler précisément et clairement, sans baratin, ce qui est une conséquence directe de la loi des grands nombres ?

en 2014 (10 ans déjà...) :

Dlzlogic a écrit:Si on lance une pièce un grand nombre de fois le TCL dit bien que la différence entre le nombre de pile et le nombre de face tend vers zéro

source : les-mathematiques.net/vanilla/discussion/894266/moyenne-ecart-type-et-variance/p2

Pivot a écrit:en 2014 (10 ans déjà...) :

Dlzlogic a écrit:
Si on lance une pièce un grand nombre de fois le TCL dit bien que la différence entre le nombre de pile et le nombre de face tend vers zéro

source : les-mathematiques.net/vanilla/discussion/894266/moyenne-ecart-type-et-variance/p2

J'ai relu avec un certain amusement une partie de ce fil.
C'était à l'époque où ce forum permettait d'avoir plusieurs pseudo, et Gbzm,, fin stratège, en a profité. Je crois que maintenant, il procède autrement. Mais ce n'est pas le problème.

Pour Humx3, oui je n'ai pas conservé l'article qui parlait de "anomalie" de la formule des générateurs de l'époque. Je ne suis pas comme certain qui gardent trace de tout ce qui à leur avis peut servir de contre-exemple. C'est marrant, certains semblent ne s'intéresser qu'à ce qui est négatif.

HumHumHum a écrit:
Pouvez vous formuler précisément et clairement, sans baratin, ce qui est une conséquence directe de la loi des grands nombres ?

La loi des grands nombres s'intéresse, comme son nom l'indique à un grand nombre d'épreuves. "La fréquence tend vers la probabilité" [Levallois page 142]. Il ne s'agit en aucun cas de probabilité ou d'équiprobabilité élémentaire (1/2 pour une pièce équilibrée) mais pour le résultat d'un grand nombre de tirages. En d'autres termes, la pièce ne sait pas qu'elle a une chance sur deux de faire pile, par contre on démontre que pour un grand nombre, on tend vers l'équilibre.

La loi des grands nombres n'a donc pas pour conséquence
- que la différence entre le nombre de piles et le nombre de faces tend vers 0 quand le nombre de lancers tend vers l'infini,
- ni même que s'il y a eu 40 piles ou moins lors des 100 premiers lancers, alors pile a plus de chances de sortir au 101^e.
Ça a juste pour conséquence que même s'il y a eu 40 piles ou moins lors des 100 premiers lancers, la fréquence des piles tend presque sûrement vers 1/2 quand le nombre de lancers tend vers l'infini.

Il ne s'agit en aucun cas de probabilité ou d'équiprobabilité élémentaire (1/2 pour une pièce équilibrée)

Ah bon, ce n'est pas là-dessus que Levallois base tout son raisonnement ?

Non, Levallois ne base pas son raisonnement sur des négations comme certains matheux savent le faire.