π, ce nombre si emblématique des mathématiques, a cette fâcheuse tendance à apparaître partout, et surtout là où on ne l’attend pas. Facétieux, il se cache dans tous les recoins des mathématiques… même les plus inattendus !
À l’origine, π est le rapport entre la circonférence d’un cercle et son diamètre : c’est comme ça qu’on l’a découvert dans l’antiquité et que sa folle histoire a commencé. Déjà en 2000 avant notre ère, on en retrouvait la trace, certes très approximative.
On retrouve π dans beaucoup de formules de géométrie bien sûr, π étant issu de cette branche des mathématiques, mais aussi dans des séries, autour des nombres complexes, en statistiques, dans bien des branches de la physique ou de la chimie au détour d’équations…
Aujourd’hui, histoire de parler d’inattendu dans tous les sens du terme, retrouvons-le dans le hasard. Car il s’y cache aussi !
π tiré au sort ?
Alors bien sûr on ne va pas tirer des nombres au hasard jusqu’à tomber par (énorme) chance sur π ! On va être un peu plus intelligent que ça… en tirant deux nombres. Attendez, vous allez comprendre…
Une histoire de nombres premiers entre eux
Tout nombre entier peut s’écrire comme le produit d’autres nombres : jusque-là, rien de bien compliqué. Si on prend quelques nombres et qu’on les écrit de la sorte, on obtient quelque chose comme ça :
Si on regarde les nombres deux par deux, on aura dans certains cas des facteurs en commun (par exemple, 100 et 40 partagent 2 et 5). Dans d’autres cas, il n’y en a pas (11 et 12 ne partagent rien) : on dit alors que ces nombres sont premiers entre eux.
Quand on tire deux nombres au hasard, il y a donc deux possibilités : ils peuvent être premiers entre eux, ou ne pas l’être.
Par exemple, j’ai tiré avec deux dés à cent faces les nombres 77 et 87 : 87 s’écrit 3 × 29 et 77 = 7 × 11 — ils sont premiers entre eux, ne partageant aucun facteur commun. J’ai relancé mes dés pour trouver 2 et 14 : 2 est premier et 14 s’écrit 2 × 7 — ils ne sont donc, eux, pas premiers entre eux.
Expérimentons : tirons plein de nombres !
Mais so what, me diriez-vous, où trouve-t-on π là-dedans ? Dans les probabilités ! Car en tirant deux nombres au hasard, on n’a pas autant de chance d’avoir deux nombres premiers entre eux que de nombres qui ne le sont pas. Lancez plein de dés, vous verrez : vous obtiendrez plus souvent des nombres premiers entre eux que le contraire. Cette probabilité se calcule, et devinez quoi ? Elle est liée à π !
En effet (et je le justifierai plus loin),
La probabilité que deux nombres tirés au hasard soient premiers entre eux vaut
Comment vérifier ça ? Un moyen simple est de… tirer plein de nombres. En réalisant l’expérience tout plein de fois et en comptant quel pourcentage de couples premiers entre eux on a obtenu, on approche la probabilité expérimentalement .
Oh, on pourrait tirer des milliers de couples de dés et vérifier que les nombres obtenus sont premiers entre eux… mais ce serait un peu longuet.1 Comme j’ai un peu la flemme, j’ai décidé d’écrire un petit programme qui fait tout le boulot pour moi, ce qui me permet de faire des millions (ou milliards si l’envie m’en prend) de tirages sans effort. Ha !
Commencer doucement…
Comme il faut savoir commencer petit, j’ai démarré avec un millier de tirages. J’ai obtenu 643 couples de nombres premiers entre eux, ce qui fait une probabilité expérimentale, basée sur ce tirage, de :
On aurait donc ? Si oui, ça donnerait :
et donc :
Je vous l’accorde, la précision n’est pas extraordinaire… mais tout de même, pour à peine un millier de paires de nombres tirés au hasard, retrouver π avec une précision de 2 %, c’est pas si mal ! Cela dit, on peut faire mieux.
Comme ce n’est pas moi qui lance les dés, autant se faire plaisir : partons sur un million de tirages. En moins d’une seconde, c’est bon, et on a trouvé 607 780 couples de nombres premiers entre eux. En appliquant le même calcul que plus haut, avec une probabilité expérimentale de , on trouve :
Voilà qui n’est pas si mal ! Certes, dès la quatrième décimale on perd la précision (elle devrait être un 5, la vraie valeur commençant par 3,14159) — mais encore une fois, on tire cette valeur du hasard complet, donc une précision de 0,01 % c’est relativement acceptable. Surtout qu’en pratique, prendre 3,14 comme approximation de π, ça suffit à la majorité des usages…
…mais finir gourmand
Dans un brin de folie (et surtout car ça travaille tout seul pendant que je fais autre chose), j’ai demandé dix milliards de tirages (oui, 10 000 000 000 de tirages). Après seulement trois heures et quart de calcul (ahrem)2, 6 079 281 509 couples de nombres premiers entre eux avaient été tirés, ce qui nous permet d’estimer que π a pour valeur…
C’est déjà mieux : on a quatre décimales justes (la vraie valeur étant π = 3,141592…) !
Le code source, pour les curieuses et les curieux
Il n’y a en soit rien de très complexe dans le programme de tirage, pour qui connaît un peu la programmation : il s’agit juste de calculer le PGCD de plein de nombres tirés au hasard, et de compter ceux pour lesquels le PGCD vaut 1 (correspondant au cas où les nombres sont premiers entre eux). Ensuite, en divisant ce nombre par le nombre total de tirages, on obtient la probabilité d’avoir deux nombres premiers entre eux, soit une approximation de . Un peu de maths en plus et on extrait une approximation de π .
J’ai juste ajouté par dessus un petit calcul de la précision en se basant sur la valeur de π “réelle” (à 15 décimales).
Le programme a été fait en Rust, parce que c’est rapide (j’avais pour volonté de tirer beaucoup de couples de nombres pour avoir une précision correcte) et que j’aime bien le langage (totalement subjectif, oui).
extern crate gcd;
extern crate rand;
use std::env;
use gcd::Gcd;
use rand::Rng;
use std::f64::consts::PI;
const DEFAULT_DRAWS: u64 = 1_000_000;
const MAX_NUMBER: u128 = std::u128::MAX;
#[inline(always)]
fn are_randoms_coprime<R: Rng>(rng: &mut R) -> bool {
rng.gen_range(1, MAX_NUMBER).gcd(rng.gen_range(1, MAX_NUMBER)) == 1
}
fn main() {
let args: Vec<String> = env::args().collect();
let draws: u64 = args.get(1).unwrap_or(&String::new()).parse().unwrap_or(DEFAULT_DRAWS);
let mut rng = rand::thread_rng();
let coprimes = (1..draws)
.filter(|_| are_randoms_coprime(&mut rng))
.count() as f64;
let pi = (6_f64 / (coprimes / draws as f64)).sqrt();
let precision = (pi - PI).abs() / PI * 100_f64;
println!("{} coprimes in {} draws", coprimes, draws);
println!("π ≈ {} (precision {} %)", pi, precision);
}
En le lançant pour un million de tirages, on peut trouver la valeur obtenue plus haut — bien sûr, comme c’est aléatoire, la valeur exacte change un peu à chaque fois mais la précision reste sensiblement la même, entre 0,1 et 0,01 %.
$ cargo run --release --quiet
607780 coprimes in 1000000 draws
π ≈ 3.141972812647824 (precision 0.01210083864935896 %)
Avec dix milliards de tirages, c’est… un peu plus long, mais le résultat est bien meilleur !
$ cargo run --release --quiet -- 10000000000
6079281509 coprimes in 10000000000 draws
π ≈ 3.14158994300916 (precision 0.0000862804128715215 %)
Pourquoi ça marche ?
Bon allez, il est temps de rentrer un peu dans les mathématiques afin de comprendre d’où vient cette probabilité !
Cette section rentre dans des détails mathématiques. J’ai tenté d’être le plus clair possible même si vous n’avez pas de grosses connaissances (les maths du collège français, étudiées vers 14/15 ans, devraient suffire), mais si vous n’êtes pas à l’aise ou que l’explication ne vous intéresse pas, vous pouvez me faire confiance et sauter à la partie suivante.
Partons de ce qu’on cherche. Avec et deux entiers naturels quelconques (ceux qu’on tire au dé), on cherche la probabilité qu’ils soient premiers entre eux, autrement dit que leur plus grand diviseur commun (PGCD) soit égal à 1.
En effet, si le PGCD vaut 1, les deux nombres ne peuvent partager aucun autre facteur commun (car alors il serait plus grand que 1, et donc le PGCD ne vaudrait pas 1) ; ils sont donc premiers entre eux.
Pour la suite, on va noter cette probabilité (vous comprendrez assez vite pourquoi ce 1 en indice), et on la note ainsi :
Une première observation que l’on peut faire, c’est qu’on peut avoir des nombres arbitrairement grands ici (et même potentiellement très grands, la seule limite étant l’infini). Le plus grand diviseur commun de deux nombres peut donc être, lui aussi, aussi grand que l’on veut. peut valoir 1, ou 2, ou 3, ou… ou , ou , ou… jusqu’à l’infini.
Mais alors, il est certain que le PGCD a l’une de ces valeurs. Donc si on somme la probabilité que le PGCD soit 1, et soit 2, et 3, et…, et , et…, jusqu’à l’infini, on doit trouver 1 (la probabilité certaine).
Autrement dit, si on note la probabilité que le PGCD de et soit :
…alors on sait que :
Ce qu’on peut écrire d’une façon un peu plus compacte :
On va donc tenter de déterminer la probabilité que le PGCD de et soit , c’est peut-être plus simple…
Alors, dans quels cas est-ce que ?
Réfléchissons. Pour que le PGCD de et soit , il faut respecter deux critères en même temps :
- doit diviser et (c’est mieux… sinon il aura du mal à être le plus grand diviseur) ; et
- il ne doit pas y avoir de diviseur plus grand que .
Pour trouver la probabilité , il nous faut donc trouver la probabilité de ces deux événements et les multiplier (car on veut les deux en même temps, et que ces événements sont indépendants les uns des autres).
Probabilité que divise et
Quand on y pense,
- 2 divise la moitié des nombres (tous les nombres pairs) ;
- 3 en divise un tiers (3, 6, 9, 12, …) ;
- 4 en divise un quart…
En généralisant, un nombre quelconque divise un -ième des nombres… la probabilité qu’il en divise un en particulier est donc — par exemple, 2 divise la moitié des nombres, donc en prenant un nombre au hasard, il y a une chance sur deux qu’il soit divisible par deux (autrement dit, pair).
Une autre façon de s’en convaincre est que dans la division d’un nombre quelconque par , il peut y avoir restes différents : 0, 1, 2, …, et . Le seul bon cas est celui où le reste est nul ; comme on a autant de chance de tomber sur l’un ou l’autre des restes, la probabilité de tomber sur zéro est bien .
Ici on veut que divise et . La probabilité qu’on cherche est donc celle que divise multipliée par celle que divise . Les deux nombres n’ayant pas particulièrement de différence de traitement, cette probabilité est bien sûr la même, et la probabilité que divise et vaut donc .
Probabilité qu’il n’y ait pas de diviseur plus grand que
On veut qu’il n’y ait pas de diviseur commun plus grand que : c’est équivalent au fait qu’il n’y ait pas de diviseur plus grand que 1 si on divise par (autrement dit que le soit 1)3.
Pour s’en convaincre, il suffit de regarder un cas particulier : disons 42 et 70. , et , donc leur plus grand commun diviseur est . Si on divise par quatorze, il ne nous reste que 3 d’un côté, et 5 de l’autre.
Si 14 n’avait pas été le plus grand diviseur commun, en divisant par lui, il serait resté de tels diviseurs, et alors le PGCD des versions divisées n’aurait pas été 1. Par exemple, si on s’était trompé et qu’on avait considéré 7 comme le PGCD, il serait resté d’un côté et de l’autre : le PGCD de ces deux nombres vaut 2 (ça se voit), et non 1.
Mais attendez, la probabilité que deux nombres aient un PGCD de 1… on l’a déjà nommée plus haut, c’est !
Revenons donc à ce qu’on cherchait…
Si on rassemble ces deux points, on peut donc affirmer que , la probabilité que le PGCD de et vaille , vaut le produit de ces deux valeurs trouvées, donc :
Or, on avait plus haut une relation avec ! Et si on essayait d’injecter cette nouvelle valeur ? On obtient :
Or est une constante, on peut donc factoriser pour la sortir de la somme :
Et donc en réorganisant :
On avance ! Il ne nous reste plus qu’à déterminer ce mystérieux terme : la somme des inverses des carrés de tous les nombres entiers positifs non nuls… mais il se trouve que c’est un problème connu, le problème de Bâle, résolu par Euler en 1741. Et il se trouve que justement… on y retrouve… π !
De là, il est trivial de conclure que :
Et voilà.
Il y a une faiblesse dans cette démonstration : il n’existe pas de probabilité uniforme sur l’ensemble des entiers strictement positifs . La démonstration ci-dessus est juste (avec quelques menus ajustements) si on considère qu’on calcule la probabilité d’avoir deux nombres premiers entre eux dans un ensemble fini (), et qu’on prend pour probabilité finale la limite de cette valeur quand tend vers l’infini :
On peut justifier que prendre ainsi la limite a un sens en terme de probabilités, mais je ne l’ai absolument pas fait ici — faites-moi confiance, ou consultez d’autres preuves certes plus rigoureuses, mais bien moins accessibles.
Une méthode efficace pour obtenir π ?
Alors oui, on peut calculer π avec cette méthode, en tirant plein de nombres au dé… mais est-elle efficace ? En pratique, pas vraiment. Ou plutôt, vraiment pas.
Le problème, c’est que pour que ça fonctionne correctement, il faudrait pouvoir tirer des nombres sur l’ensemble des nombres entiers positifs qui existent, donc jusqu’à l’infini. Et l’infini, c’est grand.
Si on ne tire pas des nombres sur tout ça, la précision s’en ressent beaucoup (vraiment beaucoup). Avec un gros dé on tire entre quoi, un et deux-cent ? C’est ridiculement petit… et on obtient au mieux zéro ou une décimale. Et même avec le logiciel que j’ai écrit pour faire les tirages à ma place, en prenant le plus grand nombre possible facilement, un nombre à trente-huit chiffres tout de même4, tellement grand qu’il est difficile de se l’imaginer — on est très, très loin de l’infini, et on peine à dépasser quatre ou cinq décimales.
Lorsqu’on calcule π avec une très grande précision, espérant des milliards de chiffres après la virgule, on utilise des méthodes très différentes et bien plus efficaces, donc on pourrait éventuellement parler s’il y a de l’intérêt parmi mes lecteurs. Mais ces méthodes n’ont pas la poésie de tirer π du hasard le plus total…
La valeur de la probabilité est juste, certes, c’est bien . Mais le fait est que cette probabilité vaut uniquement si on tire un nombre dans l’ensemble des entiers positifs non nuls (cf. la formulation sous forme de limite plus haut, si vous connaissez cette notion).
Problème : la convergence est extrêmement lente. Il faut énormément augmenter la taille de l’échantillon pour avoir une précision de qui augmente un peu. Et quand ce n’est pas le cas, on peut toujours faire des centaine de milliards de tirages : la probabilité ne permet pas d’atteindre π, mais une valeur qui s’en approche.
J’aime beaucoup cette tendance de π à pointer le bout de son nez un peu partout en mathématiques sans vraiment qu’on s’y attende. Tel un discret ange gardien qui n’est jamais très loin, caché derrière un mur prêt à bondir dans tous les domaines des sciences…
Le tirer du hasard est d’autant plus surprenant, c’est pourquoi j’avais envie d’en parler à l’occasion du π–day de cette année. Cela dit, la démonstration ci-dessus pourrait vous laisser un peu… frustré⋅e. π semble arriver tel un cheveu sur la soupe qu’il faut accepter sans broncher, ce qui n’est, je l’admets, pas très satisfaisant.
Il existe une démonstration que je trouve très élégante et compréhensible du problème de Bâle, qui permet de très bien comprendre d’où sort ce π. On peut relier ce problème à un problème géométrique impliquant des cercles, et qui dit cercle… dit π . La preuve est assez longue et ne sera pas traitée dans cet article — cela dit, une suite est prévue pour justement la présenter, et ainsi comprendre complètement comment on obtient π à partir du hasard .
Les curieux anglophones et à l’aise avec les mathématiques pourront également consulter la sixième source dans le bloc masqué ci-dessous.
Cette méthode n’est pas la seule qui existe pour extraire π du hasard, sois dit en passant. Il existe notamment la méthode de Monte-Carlo qui permet d’estimer une valeur de (et donc par extension de π) assez simplement. J’ai préféré traiter le théorème de Cesàro car je le trouve plus amusant, mais c’est complètement subjectif.
Je tiens à remercier Pifra pour ses conseils sur le traitement d’une partie de l’article, ainsi que @Aabu pour la relecture et validation de cet article dans des délais assez courts !
Sources, références, et crédits
Sources et références pour aller plus loin
- Hardy, G. H., & Wright, E. M. (2007). Introduction à la théorie des nombres. Vuibert ; Springer.
- Pi et les nombres premiers : . (s. d.). Consulté 11 mars 2020.
- Probability of Two Integers Being Coprime. (s. d.). Consulté 11 mars 2020.
- Probability that two random numbers are coprime is . (s. d.). Mathematics Stack Exchange. Consulté 11 mars 2020.
- Problème de Bâle. (2020). In Wikipédia.
- Wastlund, J. (s. d.). Summing inverse squares by euclidean geometry. 10.
Crédits
- L’allégorie de π, blob peek, est diffusée sous licence Apache 2 par Google / blobs.gg.
- La bannière est un travail dérivé de Dice par Flaticon / Those Icons.
- Cela dit, si vraiment vous y tenez, Matt Parker l’a fait (en anglais, avec 500 couples de nombres tirés).↩
- Comme vous pouvez le voir dans le bloc secret un peu après, le code qui a fait ce calcul n’est pas parallélisé, ce qui explique la durée énorme de calcul alors qu’on aurait pu faire beaucoup mieux en tirant plein de nombres en même temps. Cela dit et comme nous le verrons plus loin, même avec un système massivement parallélisé pour faire le plus de tirages possibles, cette méthode n’est franchement pas la meilleure, et certainement pas celle qu’est utilisée pour calculer des dizaines de milliards de décimales de π !↩
- est bien un entier, car on se place dans le cas où divise (sinon ça n’a pas d’intérêt, vu qu’on veut que les deux soient vrais en même temps).↩
- Pour ceux à qui ça parle, j’ai pris la valeur maximale d’un entier non-signé de 128 bits. Ce nombre vaut environ , ou exactement .↩