Floating-Point Usage on GitHub: A Large-Scale Study of Statically Typed Languages

Cette étude empirique à grande échelle analyse l'utilisation de l'arithmétique à virgule flottante dans des millions de dépôts GitHub de langages typés statiquement, révélant que les benchmarks existants ne reflètent que partiellement la réalité du code et publiant un jeu de données de 10 millions de fonctions pour guider les futures recherches.

L'essentiel

🕵️‍♂️ L'Enquête : "Où sont les nombres flottants ?"

Imaginez que le code informatique est une immense bibliothèque remplie de millions de livres (des projets de code). Dans ces livres, il y a des calculs mathématiques très précis, appelés "arithmétique à virgule flottante". C'est ce que les ordinateurs utilisent pour faire des calculs avec des nombres décimaux (comme 3,14 ou 0,001), essentiels pour la météo, les jeux vidéo, l'intelligence artificielle, etc.

Le problème ? Les experts qui essaient de vérifier si ces calculs sont justes (les "détectives du code") travaillent souvent avec de petits échantillons de livres qu'ils ont choisis eux-mêmes. Ils se demandent : "Est-ce que nos petits échantillons ressemblent vraiment à la réalité, ou sommes-nous en train d'entraîner nos détectives sur des cas trop simples ?"

Pour répondre à cette question, trois chercheurs de l'Université d'Uppsala (en Suède) ont décidé de faire le grand ménage dans la plus grande bibliothèque du monde : GitHub.

🔍 La Méthode : Un Tamis Géant

Au lieu de lire chaque livre un par un (ce qui prendrait des siècles), ils ont construit un tamis géant et automatisé (un robot) pour trier les livres.

1. Le Tamisage (Le Filtrage) : Ils ont pris un échantillon aléatoire de millions de projets. Ils ont jeté les "fausses" bibliothèques (les projets vides, les copies d'autres projets, ou les projets trop récents qui n'ont pas eu le temps de grandir).
2. La Recherche de Mots-Clés : Comme ils ne pouvaient pas lire tout le code, ils ont cherché des "mots magiques" dans les livres. Par exemple, ils ont cherché les mots float, double, sin, cos ou NaN. C'est comme chercher des indices rouges dans un livre blanc.
3. Le Nettoyage : Ils ont retiré les doublons (des livres identiques copiés-collés) pour ne compter que les histoires uniques.

Le résultat ? Ils ont extrait 10 millions de fonctions (de petits blocs de code) qui utilisent ces nombres spéciaux. C'est leur "trésor" de données.

📊 Ce qu'ils ont Découvert (Les Faits Surprenants)

Voici les trois grandes révélations de l'enquête, expliquées simplement :

1. Les nombres flottants sont partout ! 🌊

Avant, on pensait que ces calculs complexes étaient rares ou réservés aux scientifiques.

• La réalité : Plus de 62 % des projets de code sur GitHub contiennent ces calculs. C'est comme si, dans une ville, plus de la moitié des maisons avaient une piscine. C'est omniprésent !

2. Les "Vrais" livres sont différents des "Livres d'entraînement" 📚 vs 🧸

C'est le point le plus important. Les chercheurs ont comparé leurs millions de "vrais" livres avec les petits livres utilisés pour entraîner les détectives (les benchmarks comme FPBench).

• La différence : Les livres d'entraînement sont comme des puzzles simplifiés. Ils sont propres, isolés, et contiennent beaucoup de fonctions mathématiques pures (comme sin ou cos).
• La réalité : Les vrais livres sont chaotiques. Ils sont remplis de conditions ("si ça arrive, fais ceci"), de boucles ("répète ça 10 fois") et de mélanges de différents types de données.
• L'analogie : C'est comme entraîner un pilote de course sur un circuit vide et plat, puis le lancer sur une route de montagne pleine de virages, de nids-de-poule et de pluie. Les outils actuels sont excellents sur le circuit vide, mais ils paniquent sur la vraie route.

3. La taille des problèmes 🐜 vs 🐘

On pensait que les problèmes de calcul étaient de gros monstres complexes.

• La réalité : La plupart des fonctions sont en fait petites et modulaires. C'est comme une équipe de Lego : au lieu d'un seul bloc géant, on a des milliers de petits blocs qui s'assemblent. Le défi pour les détectives n'est pas de résoudre un seul monstre, mais de comprendre comment des milliers de petits blocs interagissent entre eux.

🛠️ Pourquoi c'est important ? (Le "Pourquoi" de l'histoire)

Aujourd'hui, les outils qui vérifient la sécurité des calculs (pour éviter qu'un avion ne tombe ou qu'un médicament soit mal dosé) sont entraînés sur des exemples "trop propres".

• Le risque : Si on ne les entraîne pas sur la vraie complexité du monde réel, ils pourraient dire "Tout va bien !" alors qu'il y a un danger caché.
• La solution : Les chercheurs ont créé un nouveau jeu d'entraînement (un ensemble de 59 exemples réels en C) basé sur leur découverte. C'est comme donner aux pilotes un simulateur de vol avec de la vraie météo, pas juste du vent calme.

🎯 En Résumé

Cette étude est un réveil pour la communauté scientifique. Elle dit : "Arrêtez de vous entraîner sur des cas idéaux ! Regardez comment les développeurs écrivent vraiment du code : c'est plus petit, plus mélangé, et plus complexe."

Grâce à cette étude, les futurs outils de vérification pourront être conçus pour être plus robustes, capables de naviguer dans le vrai chaos du code informatique, et ainsi rendre nos technologies numériques plus sûres pour tout le monde.

La morale de l'histoire ? Pour bien réparer une voiture, il ne faut pas regarder uniquement les plans du constructeur, mais aller voir comment les mécaniciens réparent vraiment les voitures dans la rue. C'est exactement ce que ces chercheurs ont fait pour le code. 🚗💻✨

Résumé technique

Voici un résumé technique détaillé de l'article "Floating-Point Usage on GitHub: A Large-Scale Study of Statically Typed Languages" (Utilisation des nombres à virgule flottante sur GitHub : Une étude à grande échelle des langages typés statiquement).

1. Problématique et Contexte

Le raisonnement sur l'arithmétique à virgule flottante est notoirement difficile en raison des erreurs d'arrondi, des valeurs spéciales (NaN, infini) et de la complexité des opérations. Bien que des techniques d'analyse statique et dynamique aient progressé, leur pertinence pour le code réel reste incertaine.

Le problème central identifié par les auteurs est le décalage entre les benchmarks utilisés dans la littérature académique et le code réel.

• Les outils d'analyse sont souvent évalués sur de petits ensembles de benchmarks "à la main" (hand-picked), comme FPBench ou des sous-ensembles de la GNU Scientific Library (GSL).
• Ces benchmarks sont souvent des expressions arithmétiques isolées, ne reflétant pas la complexité structurelle (boucles, conditions, appels de fonctions imbriqués) du code produit par les développeurs.
• Il n'existe pas d'étude à grande échelle sur la prévalence et les caractéristiques réelles du code à virgule flottante dans les projets open-source, ce qui empêche de savoir si les outils actuels sont évalués sur des cas d'usage représentatifs.

2. Méthodologie

Les auteurs ont conçu une méthodologie de "mining" (exploration) de code entièrement automatisée et reproductible, implémentée dans un framework nommé Scyros (écrit en Rust). L'étude se concentre sur les langages typés statiquement pour permettre une identification fiable des types de données sans exécution du code.

Le pipeline de sélection des données comprend les étapes suivantes :

1. Échantillonnage aléatoire : Extraction uniforme d'identifiants de dépôts GitHub via l'API REST, en excluant les forks.
2. Filtrage par métadonnées : Élimination des projets "toy" (projets non significatifs) :
   • Taille < 50 ko.
   • Âge < 2 mois (pour éviter les devoirs d'étudiants).
   • Pas de langage principal assigné.
3. Filtrage par langage : Sélection des dépôts contenant au moins un langage typé statiquement (51 langages identifiés, dont C, C++, Java, TypeScript, Go, C#, etc.).
4. Téléchargement et Dé-duplication :
   • Téléchargement du contenu des dépôts filtrés.
   • Élimination des doublons au niveau des tokens (hash BLAKE3) pour éviter les biais liés à la réutilisation massive de code (ex: fichiers de déclaration TypeScript).
5. Détection par mots-clés (Keyword-based) :
   • Identification des fichiers contenant des types flottants (float, double, real) ou des fonctions mathématiques (sin, exp, NaN, inf).
   • Suppression des commentaires et des littéraux de chaînes pour réduire les faux positifs.
6. Extraction de fonctions :
   • Utilisation de la bibliothèque de parsing Tree-sitter pour extraire les fonctions individuelles.
   • Analyse structurelle : comptage des lignes, paramètres, boucles, conditions, appels de fonctions et profondeur d'imbrication.

Données collectées : 447 209 projets analysés, aboutissant à un jeu de données final de 10 millions de fonctions à virgule flottante.

3. Contributions Clés

1. Première étude à grande échelle : Une analyse quantitative de la prévalence et des caractéristiques du code à virgule flottante dans des millions de dépôts GitHub.
2. Jeu de données public : Publication d'un corpus de 10 millions de fonctions extraites, servant de base pour de nouveaux benchmarks réalistes.
3. Évaluation des benchmarks existants : Une comparaison rigoureuse entre les fonctions réelles et les benchmarks standards (FPBench, GSL).
4. Outil Scyros : Mise à disposition open-source d'un framework modulaire pour l'analyse à grande échelle de code.
5. Benchmarks de défi (Challenge Benchmarks) : Extraction de 59 benchmarks C auto-contenus illustrant des patterns de code réels complexes.

4. Résultats Principaux

A. Prévalence (RQ1)

• Très élevée : Avec 95 % de confiance, plus de 62 % des projets open-source typés statiquement contiennent du code à virgule flottante.
• La présence est souvent concentrée dans un petit nombre de fichiers au sein d'un projet.

B. Caractéristiques du Code (RQ2)

• Taille : Les fonctions sont généralement petites (médiane de ~30 lignes de code).
• Structure :
  • Les appels de fonctions sont très fréquents (plus que les boucles).
  • Les conditions (if) sont omniprésentes (jusqu'à 63 % des fonctions en Go).
  • Les boucles sont moins fréquentes que les conditions, mais leur présence est significativement plus élevée dans le code flottant que dans le code non numérique (même à taille égale).
  • Les valeurs spéciales (NaN, infini) sont rares dans le code source explicite.
• Précision : Le simple (32-bit) et le double (64-bit) dominent largement. Les précisions mixtes, demi-précision (16-bit) ou quad (128-bit) sont rares.
• Langages : C, C++, Java, TypeScript, C# et Go représentent plus de 92 % du corpus.

C. Représentativité des Benchmarks (RQ3)

• FPBench n'est pas représentatif :
  • Les fonctions FPBench contiennent beaucoup plus d'appels à des fonctions transcendantes (sin, cos, exp) que le code réel.
  • Elles contiennent beaucoup moins de conditions et de boucles.
  • La combinaison "Boucle + Condition + Appel de fonction" est rare dans FPBench (1,5 %) mais courante dans le code réel (26 % en C).
• GSL sous-utilisée : Les fonctions de la GNU Scientific Library, souvent utilisées pour l'évaluation, apparaissent dans moins de 0,2 % des fichiers et fonctions analysés.

5. Signification et Implications

• Redirection de la recherche : Les outils d'analyse actuels sont optimisés pour des noyaux numériques isolés et simples (comme dans FPBench), alors que le code réel est modulaire, riche en contrôle de flux (conditions/boucles) et utilise peu de fonctions mathématiques transcendantes.
• Défis pour les outils : Pour être utiles, les futurs outils d'analyse doivent maîtriser :
  • La modularité (analyse interprocédurale).
  • Le raisonnement sur les branches conditionnelles (le comportement flottant peut varier selon le chemin d'exécution).
  • La gestion des boucles et de l'accumulation d'erreurs dans des contextes complexes.
• Limites : L'approche par mots-clés est efficace pour les langages typés statiquement mais difficilement applicable aux langages dynamiques (Python, JS) sans exécution du code, ce qui pose un défi pour une étude future plus large.

En conclusion, cette étude fournit une base factuelle pour réévaluer les critères d'évaluation des outils d'analyse numérique et suggère que la communauté doit se concentrer sur des benchmarks reflétant la complexité structurelle du code de production plutôt que sur des expressions mathématiques isolées.