Uncertain<T>

• Présentation du concept du type Uncertain<T>, une nouvelle abstraction pour gérer l’incertitude au niveau du code
• Ce type applique une approche de programmation probabiliste afin de modéliser la confiance ou la possibilité d’une valeur, au lieu de la logique booléenne traditionnelle
• Il permet de traiter des données réelles bruitées comme le GPS ou les données de capteurs sous forme de distributions de probabilité mathématiques
• Il prend en charge un équilibre entre efficacité de calcul et fiabilité des résultats grâce à des techniques d’échantillonnage comme le SPRT et les méthodes de Monte Carlo
• Son intégration progressive avec le code existant en fait une solution très applicable en pratique

---

Encoder l’incertitude : l’écart entre la confiance et les données du monde réel

• Le texte évoque la tendance de nombreuses personnes à trop s’appuyer sur la certitude
• Il souligne qu’avec l’expérience en développement logiciel, on dit de plus en plus souvent « cela dépend du contexte »
• Pourtant, dans le code, on continue de répéter des schémas fondés uniquement sur des jugements vrai/faux
• Il critique en particulier le fait de n’utiliser que des valeurs booléennes pour traiter des données incertaines comme celles du GPS
• Le modèle de programmation binarise trop vite l’« incertitude » du réel et en masque ainsi la complexité

Choisir la bonne abstraction

• En 2014, l’University of Washington et Microsoft Research ont proposé un concept qui reflète directement l’incertitude dans le système de types
• L’article « Uncertain<T>: A First-Order Type for Uncertain Data » a démontré le caractère pratique d’une approche de programmation probabiliste
• Un portage du concept en Swift a été publié dans un dépôt GitHub
• Avec Uncertain<T>, le résultat des comparaisons s’exprime lui aussi comme une probabilité relative et renvoie un Uncertain<Bool> plutôt qu’une simple valeur vrai/faux
• Les erreurs de position GPS sont modélisées selon les caractéristiques des données réelles, par exemple avec une distribution de Rayleigh

La réalité des différentes opérations sur l’incertitude

• Le système prend en charge plusieurs opérateurs et modèles de distributions de probabilité, construit un graphe d’opérations et n’exécute l’échantillonnage que lorsque c’est nécessaire
• Il utilise le SPRT (Sequential Probability Ratio Testing) pour ajuster efficacement le nombre d’échantillons
• Les exemples de code expliquent la différence de nombre d’échantillons nécessaires entre une comparaison simple et une comparaison composée
• Cette abstraction permet de ne pas ignorer l’incertitude et de l’exploiter naturellement dans le calcul, afin d’écrire un code plus « intelligent »

Application de la méthode de Monte Carlo

• Un échantillonnage Monte Carlo est introduit pour l’analyse des distributions de probabilité et l’estimation des valeurs attendues
• En pratique, on peut obtenir facilement une espérance en simulant de manière répétée le résultat d’une machine à sous
• Même sans calcul analytique complexe, de simples échantillonnages répétés par ordinateur permettent d’obtenir des résultats réalistes

Une modélisation riche des distributions de probabilité

• Uncertain<T> intègre divers constructeurs de distributions de probabilité, ce qui permet de modéliser finement des données du monde réel comme le bruit des capteurs, le comportement utilisateur ou la latence réseau
• Il prend en charge la paramétrisation selon les cas pour plusieurs distributions, notamment mixture, Bernoulli, exponential et normal
• Un projet de visualisation interactif est également proposé pour aider à comprendre intuitivement chaque distribution

Fonctions statistiques et analytiques fournies

• Le système fournit de nombreuses fonctions statistiques : espérance, écart-type, intervalle de confiance, asymétrie (skewness), kurtosis, entropie, etc.
• Les résultats peuvent être calculés avec un nombre d’échantillons ajustable, ce qui permet un compromis entre précision et efficacité
• Il est également facile de calculer la probabilité qu’une valeur soit inférieure ou égale à un certain seuil à l’aide de la fonction de répartition cumulative (CDF)

Guide d’application au monde réel

• Le texte explique les problèmes concrets qui peuvent survenir dans une app quand l’incertitude est ignorée (par exemple une vitesse GPS manifestement absurde)
• Il insiste sur une transition progressive : il est recommandé d’intégrer Uncertain<T> d’abord de manière partielle, à partir de parcours critiques comme la mesure de distance
• Il est possible d’ajuster l’équilibre entre précision et performance via des paramètres de coût de calcul, comme le nombre d’échantillons
• En pratique, il recommande d’utiliser activement des outils de profiling comme Instruments.app
• L’objectif n’est pas d’éliminer l’incertitude, mais de reconnaître son existence et d’adopter des schémas de développement adaptés

Conclusion et perspectives

• Les développeurs peuvent introduire la gestion de l’incertitude à petite échelle pour commencer, avec l’espoir d’améliorer l’utilisabilité et d’atténuer les erreurs
• Accepter qu’une certitude totale n’existe pas permet d’élever d’un cran la qualité logicielle grâce à des outils et des abstractions adaptés
• En pratique, bien traiter l’incertitude qui existe réellement constitue la véritable amélioration utile sur le terrain

[GN⁺]

Avis Hacker News

• L’incertitude du GPS ne peut généralement être approximée par un cercle que dans des conditions particulières, comme un positionnement prolongé sous ciel dégagé ; en réalité, le modèle d’erreur global est bien plus complexe et il existe diverses façons de mesurer l’erreur. C’est important dans de nombreuses situations où il est difficile de traiter une position comme un simple point ; par exemple, dans le cas des voitures autonomes, l’incertitude de l’estimation de position est souvent dominée par des effets de trajets multiples non circulaires. Si l’on réfléchit sérieusement à ces difficultés, on finit par réinventer des techniques comme les filtres particulaires.
  • Le GPS automobile est généralement complété par plusieurs capteurs et hypothèses supplémentaires, notamment le compteur de vitesse, la boussole, ainsi que le fait de savoir que le véhicule se trouve probablement sur l’une des routes de la carte. On suppose aussi souvent qu’il n’y a pas eu de changement de position entre la dernière extinction et le redémarrage, ce qui permet une acquisition rapide de la position.
  • Les points LiDAR ne sont en réalité pas de simples points, mais des ellipsoïdes centrés sur la position la plus probable.
• À l’Université de Cambridge, quelqu’un a conçu une microarchitecture de processeur inspirée par Uncertain<T> (James Bornholt) et les recherches associées. Elle permet de charger dans les registres/la mémoire non seulement des distributions paramétriques (Gaussian, Rayleigh, etc.), mais aussi des ensembles arbitraires d’échantillons, afin que les valeurs du programme se propagent à travers les opérations arithmétiques comme des distributions non paramétriques. Une spin-off nommée Signaloid est en train de commercialiser cette technologie, et je mène moi-même des recherches pour l’appliquer à l’estimation d’état (par ex. les filtres particulaires) lien vers l’article
• Si l’on comprend l’idée qu’en programmation une variable peut contenir la « spécification » d’une variable mathématique, cela ouvre des possibilités étonnantes qui sont au fondement de l’IA moderne. Prenons la formule familière y = m * x + b : lorsque tout n’est que littéraux, ce n’est qu’une simple fonction de rendu. Mais si les variables contiennent toute la structure du chemin de calcul dont elles sont issues, alors selon le sens du calcul on peut soit prédire la valeur pour produire un rendu (forward pass), soit calculer automatiquement gradients et dérivées pour aller jusqu’à l’entraînement d’un réseau neuronal. En échantillonnant mathématiquement ces résultats, on peut obtenir les poids qui forment le modèle. Chaque couche du deep learning est conçue de cette manière, et des systèmes comme PyTorch peuvent compiler de manière optimale le simple fait de décrire la composition des opérations. Autrement dit, Uncertain<T> n’est qu’un point de départ ; si l’on imagine que toute variable numérique peut à tout moment être définie par des métadonnées représentant des valeurs candidates, et que ces métadonnées peuvent être manipulées aussi facilement qu’on additionne des valeurs, cela devient une expérimentation extrêmement intéressante.
  • Ça a l’air vraiment passionnant ; je me demande si quelqu’un pourrait l’expliquer de façon accessible même à quelqu’un comme moi, qui n’a pas beaucoup de connaissances en machine learning ou en maths.
  • Je me demande s’il existe réellement des langages de programmation qui prennent en charge ce genre de concept au niveau du langage.
  • Ce commentaire donne l’impression de mélanger variables, fonctions et systèmes linéaires ; je ne suis pas sûr qu’il soit nécessaire de tout fusionner ainsi.
• Je me demande si cette approche permet aussi de traiter la covariance entre plusieurs variables. Par exemple, la position de l’objet mesuré peut elle-même comporter une erreur, et cette erreur peut être corrélée à la mienne (encore plus si les deux ont été mesurées par le même GPS au même moment). Si le système de types ne gère que des modèles univariés, ce sera déjà utile, mais s’il peut aussi traiter la covariance, l’usage serait bien plus puissant et précis.
  • Avec une approche par échantillonnage, la modélisation de la covariance est automatiquement incluse. Il suffit d’échantillonner une seule fois les valeurs feuilles réutilisées plusieurs fois dans une même évaluation ; on peut d’ailleurs vérifier que c’est bien ainsi que fonctionne l’implémentation dans le code ci-dessous code Uncertain.swift
  • Je me demande depuis longtemps si un programme pourrait « apprendre » la covariance en usage réel. Si l’on modélise les variables indépendamment, cela finira sans cesse par s’écarter de la réalité. Et dans un programme de grande taille, prendre manuellement en compte toutes les corrélations entre paires de variables est pratiquement impossible. Il faudrait peut-être imaginer un moyen de l’apprendre automatiquement.
  • Si vous avez besoin de suivre les covariances, je recommande aussi de regarder la bibliothèque gvar pour Python.
  • Pour modéliser correctement la mécanique quantique, il faudrait associer une fonction d’onde complexe à chaque ensemble de variables intriquées.
• Dans les plans de génie mécanique et autres documents similaires, on utilise la notion de « tolérance » pour communiquer avec les opérateurs d’usinage, par ex. 10cm +8mm/-3mm, en indiquant clairement la plage admissible vers le haut et vers le bas. Pour une question fondée sur le GPS comme « est-ce qu’on est presque arrivés ? », il semble aussi important de comprendre la direction de l’erreur et de distinguer les cas meilleurs ou pires selon la « direction » de l’incertitude.
  • Le problème avec cette notation, c’est que selon les cas elle peut signifier soit « on ne dépasse absolument jamais les bornes min/max », soit « on ne les dépasse qu’avec 10 % de probabilité ».
  • C’est similaire à l’estimation en trois points (optimiste, réaliste, pessimiste), souvent utilisée dans la planification du travail. Même une distribution de probabilité très simple apporte bien plus de clarté dans tous les domaines où l’incertitude intervient.
• Cette idée a déjà été implémentée à plusieurs reprises dans le passé sous le nom d’« arithmétique d’intervalles » ; elle est aussi prise en charge par Boost et flint Boost Interval flint(arb). Malgré ces redécouvertes répétées, je me demande pourquoi cela n’est jamais vraiment devenu grand public. Si quelqu’un l’a utilisé en conditions réelles puis l’a abandonné faute de résultats satisfaisants, j’aimerais beaucoup avoir son retour.
  • Le billet explique qu’Uncertain<T> utilise une distribution de Rayleigh pour l’incertitude GPS. Une distribution de Rayleigh n’est pas une distribution uniforme ; elle modélise mieux les erreurs du monde réel. Par exemple, si l’on calcule (-2,2)*(-2,2) avec la bibliothèque Boost, on obtient (-4,4), alors qu’en pratique les valeurs extrêmes ont bien moins de chances de se produire simultanément ; quelque chose comme (-2.35,2.35) serait donc plus réaliste.
  • En physique, on apprend assez tôt la propagation des erreurs (error propagation). Si l’on suppose que les erreurs suivent une distribution gaussienne, le calcul est très élégant ; mais en réalité, la plupart des mesures ne suivent pas une distribution gaussienne, et les erreurs non probabilistes (systématiques) posent problème. Comme il est difficile de les traiter correctement, la propagation automatique des erreurs est souvent de peu d’utilité ; dans la plupart des cas, une analyse manuelle reste nécessaire.
  • Je ne comprends pas bien pourquoi cet article attire tant l’attention ; ce projet ne prend pas seulement en charge l’arithmétique d’intervalles, mais aussi diverses distributions d’incertitude.
  • Pour des types simples comme un booléen, l’inférence est facile et les contraintes sont claires. En revanche, l’incertitude physique est complexe, donc le modèle doit varier selon le domaine ; une fois qu’on décide de traiter une incertitude complexe, il vaut souvent mieux utiliser un modèle spécialisé pour cet objectif plutôt qu’une simple bibliothèque joliment emballée.
  • L’arithmétique d’intervalles n’est plus lente que d’un facteur constant par rapport à l’arithmétique numérique simple, et pour chaque opération il existe un résultat d’intervalle intrinsèquement le plus précis. Mais la précision n’est pas toujours garantie. Les graphes d’opérations par échantillonnage comme dans l’article sont plus lents, mais ils permettent en échange de mieux coller aux modèles d’erreur réels. Ils ont aussi l’avantage de ne pas nécessiter de domaine abstrait qui ferait perdre en précision.
• Le type de donnée que je voulais créer exprimerait à quel point une valeur est connue à l’intérieur d’une distribution de probabilité donnée (ou d’une fonction de densité de probabilité), et chaque transformation ajouterait sa propre part d’incertitude. J’imagine un processus où, à mesure que les observations augmentent (ou que la classification conditionnelle change), cet ensemble de distributions se raffine continuellement. À terme, l’objectif serait de simuler ce genre de cas de résultats aléatoires fondés sur des distributions.
• Ce concept est aussi étroitement lié à l’ancien Functional Pearl « Probability Functional Programming » lien PDF. C’est vraiment superbe ; dans mon premier cours d’introduction à Haskell, je commence par montrer le problème de Monty Hall avec une monade probabiliste, en calculant de façon éclatante les probabilités de victoire des deux stratégies comme des fractions entières.
  • On peut aussi consulter la bibliothèque Haskell monad-bayes billet de blog associé
• Peut-être qu’Uncertain devrait être le type de base, et qu’on ne devrait préciser certain T séparément que dans les cas vraiment certains.
  • Pour les mesures physiques, oui, sans doute ; mais pour des objets comme l’argent, il faut être exact jusqu’aux fractions d’unité. À noter que cette approche est déjà implémentée dans certaines bibliothèques Fortran modernes.
  • Cela pourrait servir de complément au type Optional.
• Je me demande si, asymptotiquement, cela revient à une version programmative de la logique floue (fuzzy logic) Wikipédia Fuzzy Logic
  • Cela ressemble plutôt à la programmation probabiliste (probabilistic programming), qui est déjà un domaine existant ; Pyro en est un exemple représentatif.