Parfait exemple d'un théorème qui paraît très simple mais qui ne l'est pas du tout.
Les mathématiques demandent une rigueur infinie.
Ça me fait penser à cette histoire qu'on raconte souvent dans les études de maths. Un jour, un prof réalise une démonstration devant ses élèves. Il laisse alors une petite partie de la démonstration en disant « ça, je ne le démontre pas, c'est évident ». Habitude de l'enseignant plus que du mathématicien.
Il regarde alors son tableau, part de la salle sans dire mot, et laisse les étudiants seuls, rejoignant son bureau. Finalement, il revient 45 minutes plus tard en disant « oui, comme je le disais, cette partie là est évidente ! »
Bref, méfions-nous des évidences. C'est vrai en mathématiques (même et surtout en probas et stats) en sciences, mais également dans la vie de tous les jours.
Excellente vidéo (et article) sur le(s) théorème(s) de Gödel.
C'est bien plus précis que la version allégée qu'on apprend parfois, mais qui n'a pas trop de sens en mathématiques.
How the f**k could it be possible ?
C'est du brain-fuck ou alors ?
Demonstrates how the end of a set of belts can be continuously rotated without becoming twisted or tangled.
À y regarder de plus près, la fiche Wikipedia apporte des informations.
Renversant !
via : https://twitter.com/pickover/status/801119620417601536
Pour le centenaire de Claude Shannon, le CNRS a fait cette jolie page.
On y parle de ses travaux, multiples, mais aussi de leurs répercutions aujourd'hui, y compris dans la recherche fondamentale.
Un site que les informaticiens devraient aller voir :)
Les constantes Oméga de Chaitin sont des nombres extraordinaires de par leur propriétés. Ils sont non calculables & aléatoires mais peuvent servir à beaucoup de choses.
Bon, je reste flou ici, mais si on s'intéresse à la théorie de Turing / calculabilité / complexité, je recommande vivement cet article.
Il y est aussi question de théorème de Gödel et donc d'incomplétude des théories mathématiques. Et, résultat très surprenant : bien qu'une telle constante soit incalculable et aléatoire, son existence permet de tirer des conclusions (propriétés) mathématiques intéressantes (quantification des problèmes décidables, rôle du nombre d'axiomes sur la complétude, etc.)
Bref, ami-e matheux-e / informaticien-ne, je te recommande cet article.
Super article de maths, qui explique notamment (parmi d'autres choses) comment sont calculées les courbes sur l'autoroute. Ainsi que, pour le résumer en tordant un peu la réalité, les problèmes de déformation quand on passe d'un espace à un autre.
Vraiment bon. Comme l'ensemble du blog (si vous aimez les maths, lisez tout et/ou regardez les vidéos : c'est que du beau)
Article FRANCHEMENT intéressant sur le théorème CAP, qui est souvent mal compris. Il m'a ouvert les yeux alors que je pensais le maitriser.
Ceci dit, les conclusions restent un peu les mêmes, mais ce qui est entendu dans les différents concepts est différent de ce que j'avais compris intuitivement (surtout sur Partition Tolerance)
Pour rappel, le théorème CAP parle de système distribués et de scalabilité :
« Dans un système distribué (reposant sur des données partagées) vous ne pouvez conserver que deux des trois propriétés suivantes :
- [en:Consistency] Consistence ;
- [en:Availability] Disponibilité ;
- [en:Partition Tolerance] Résistance au partitionnement »
Shorter : la dernière propriété n'indique pas que le système est distribué (c'est H0, l'hypothèse de base) mais l'état d'un système distribué dans lequel certains nœuds deviennent séparés (par coupure réseau, serveur en panne, etc.) d'autres nœuds. D'où l'existence de "partitions"
Finalement, ce théorème (formellement Brewer' Theorem) indique que, dans un système distribué, en cas de partionnement, il faut choisir la stratégie transactionnelle vis-à-vis des clients :
- soit refuser de répondre pour ne pas donner une réponse incohérente ou corrompre les données ;
- soit accepter de corrompre des données (éventuellement temporairement) en écriture ou renvoyer des données anciennes (inconsistantes).
Une dernière notion enfin.
Maintenir soit A soit C est élitiste, et en pratique on peut trouver un continuum de stratégies. D'où les notions de :
- [en:Yield] Rendement : c'est le pourcentage de requêtes qui seront complètement (completness + correctness) exécutées ;
- [en:Harvest] Moisson : c'est la proportion de données complètes traitées sur une requête.
C'est très intéressant de travailler avec ces deux notions, notamment pour décrire des SLA. Parce que, par exemple, le "uptime" ne reflète pas vraiment la garantie offerte : les coupures lors des creux n'ont pas le même impact que lors des pics.