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

Diese Studie analysiert erstmals in großem Maßstab die Verwendung von Gleitkommaarithmetik in öffentlich zugänglichen GitHub-Repositories statisch typisierter Sprachen, um durch die Veröffentlichung eines Datensatzes mit 10 Millionen Funktionen und den Vergleich mit bestehenden Benchmarks die Lücke zwischen theoretischen Forschungsansätzen und realer Praxis zu schließen.

Das Wesentliche

Hier ist eine einfache Erklärung der Studie, als würde man sie einem Freund beim Kaffee erzählen, mit ein paar bildhaften Vergleichen.

Das große Rätsel: Wie nutzen Programmierer eigentlich Zahlen?

Stell dir vor, du bist ein Architekt, der Brücken baut. Du hast eine Menge Werkzeuge (die "Beweis-Tools"), um zu prüfen, ob deine Brücke sicher ist. Aber hier ist das Problem: Die Werkzeuge wurden bisher nur an kleinen, perfekt gebauten Modellbrücken getestet, die in einem Labor stehen. Niemand weiß wirklich, wie die echten Brücken auf der Autobahn aussehen, die von tausenden verschiedenen Ingenieuren gebaut wurden.

Diese Studie von Andrea Gilot und ihrem Team ist wie eine riesige, weltweite Inspektion aller echten Brücken, die jemals gebaut wurden. Sie wollten herausfinden: Wie sieht "echter" Code aus, der mit Dezimalzahlen (Gleitkommazahlen) arbeitet?

Das Problem mit den alten Tests

Bisher haben Forscher ihre neuen Werkzeuge an kleinen, handverlesenen Beispielen getestet (wie dem FPBench). Das ist, als würdest du einen neuen Autotest nur an Rennwagen machen, die auf einer geraden Strecke fahren. Aber im echten Leben fahren Autos über holprige Straßen, machen scharfe Kurven und müssen Bremsen.

Die Forscher vermuteten: "Vielleicht sind unsere Tests gar nicht repräsentativ für die echte Welt." Um das herauszufinden, mussten sie in den riesigen Datenberg von GitHub (dem "GitHub" ist wie ein riesiges Lagerhaus, in dem Millionen von Programmierern ihren Code ablegen) graben.

Wie haben sie das gemacht? (Die Schatzsuche)

Da sie nicht jeden einzelnen Code-Schnipsel auf der Welt lesen konnten (das wäre wie der Versuch, alle Sandkörner am Strand zu zählen), haben sie einen cleveren Plan entwickelt:

1. Zufällige Auswahl: Sie haben nicht nur die "beliebtesten" Projekte gewählt (das wäre wie nur die besten Restaurants zu besuchen und zu denken, das sei das ganze Essen). Stattdessen haben sie zufällig Projekte ausgewählt, um ein ehrliches Bild zu bekommen.
2. Filtern: Sie haben den "Müll" entfernt. Kleine, leere Projekte oder solche, die nur ein paar Zeilen Code hatten, wurden aussortiert.
3. Der Such-Roboter: Da Computer nicht immer wissen können, ob eine Zahl eine Dezimalzahl ist (besonders bei Sprachen, die das nicht fest vorgeben), haben sie nach Schlüsselwörtern gesucht.
   • Die Analogie: Stell dir vor, du suchst in einer Bibliothek nach Büchern über "Kochen". Du suchst nicht nach jedem einzelnen Rezept, sondern suchst nach den Wörtern "Zwiebel", "Pfanne" oder "Rezept". Wenn du diese Wörter findest, ist es wahrscheinlich ein Kochbuch. Genau so suchten sie nach Wörtern wie float, double, sin (Sinus) oder NaN (eine spezielle Fehlermeldung für Zahlen).
4. Duplikate entfernen: Da viele Leute denselben Code kopieren (wie ein Rezept, das 10.000 Mal abgeschrieben wurde), haben sie die Kopien entfernt, damit die Statistik nicht verfälscht wird.

Was haben sie herausgefunden? (Die Überraschungen)

Das Ergebnis war eine Mischung aus Bestätigung und Überraschung:

• Zahlen sind überall: Über 62 % aller untersuchten Projekte nutzen Dezimalzahlen. Das bestätigt, dass diese Art von Code extrem wichtig ist.
• Die "echten" Funktionen sind klein: Die meisten Funktionen (die kleinen Bausteine im Code) sind überraschend klein. Das ist gut für die Werkzeug-Hersteller, denn sie müssen nicht riesige, komplexe Maschinen analysieren, sondern viele kleine Teile.
• Die Tests lügen (ein bisschen): Die alten Test-Suiten (FPBench) sahen ganz anders aus als die echte Welt.
  • Der Vergleich: Die alten Tests waren wie ein perfektes, gerades Rennstrecken-Layout. Die echte Welt ist wie ein Stadtverkehr mit Ampeln, Baustellen und Abbiegungen.
  • In der echten Welt gibt es viel mehr Entscheidungen (Wenn-Dann-Regeln) und Schleifen (Wiederholungen) als in den Tests. Die alten Tests hatten fast keine davon.
  • Die Tests enthielten viele spezielle mathematische Funktionen (wie Sinus oder Cosinus), die in der echten Welt viel seltener vorkommen.
• Die "GSL"-Bibliothek ist ein Mythos: Viele Forscher nutzen die "GNU Scientific Library" (GSL) als Referenz. Die Studie zeigte: Diese Bibliothek wird in der echten Welt fast gar nicht benutzt! Es ist, als würden alle Autotests nur mit einem bestimmten Modell von BMW fahren, obwohl die meisten Leute Toyota oder VW fahren.

Was bedeutet das für die Zukunft?

Die Forscher haben aus diesem riesigen Berg Daten 10 Millionen echte Funktionen extrahiert und veröffentlicht. Das ist wie ein riesiger Test-Parcours, der genau so aussieht wie die echte Welt.

Sie haben auch 59 neue, echte Testfälle erstellt (die "Herausforderungen"). Diese sind schwieriger für die alten Werkzeuge, weil sie echte Probleme wie Schleifen und Verzweigungen enthalten.

Die große Lehre:
Die Werkzeuge, die wir entwickeln, um die Sicherheit von Zahlenrechnungen zu prüfen, müssen lernen, mit echtem Chaos umzugehen. Sie müssen nicht nur gerade Strecken fahren, sondern auch durch die Kurven kommen, Ampeln beachten und mit unerwarteten Hindernissen zurechtkommen. Nur so können sie in der echten Welt wirklich helfen, Fehler zu finden, bevor sie passieren.

Zusammenfassung in einem Satz

Diese Studie hat den riesigen Datenberg von GitHub durchsucht, um zu zeigen, dass unsere bisherigen Tests für Zahlenrechnungen zu "sauber" und unrealistisch waren, und liefert jetzt echte, chaotische Beispiele, damit die nächsten Werkzeuge wirklich robust werden.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Floating-Point Usage on GitHub: A Large-Scale Study of Statically Typed Languages" auf Deutsch:

1. Problemstellung und Motivation

Die Analyse von Gleitkommaarithmetik (Floating-Point Arithmetic) ist aufgrund von Rundungsfehlern, Überläufen und speziellen Werten wie NaN (Not-a-Number) oder Infinity bekanntermaßen schwierig. Fortschritte in der statischen und dynamischen Analyse sowie bei der Programmreparatur haben zwar viel erreicht, doch fehlt es oft an Relevanz für reale Codebasen.

Ein zentrales Problem ist die Repräsentativität bestehender Benchmarks. Die in der Literatur verwendeten Testfälle (z. B. FPBench) werden oft manuell ausgewählt und spiegeln möglicherweise nicht die Struktur, Größe oder Komplexität von tatsächlichem, in der Praxis genutztem Code wider. Es ist unklar, ob diese Benchmarks die Erwartungen der Entwickler an Analyse-Tools erfüllen. Zudem gibt es keine groß angelegten empirischen Studien, die die Verbreitung und Charakteristika von Gleitkommacode in Open-Source-Projekten quantitativ erfassen.

2. Methodik

Die Autoren führen eine groß angelegte empirische Studie durch, um die Verbreitung und Eigenschaften von Gleitkommacode in öffentlich zugänglichen GitHub-Repositories zu untersuchen. Der Fokus liegt bewusst auf statisch typisierten Sprachen, da hier Typinformationen (z. B. float, double) direkt im Code sichtbar sind und eine automatisierte, skalierbare Analyse ermöglichen.

Der Prozess folgt einem mehrstufigen Mining-Pipeline-Ansatz (basierend auf etablierten Standards für Repository-Mining):

1. Stichprobenziehung (Sampling): Es werden zufällig Repository-IDs von GitHub gezogen (unter Verwendung der REST-API), um eine Verzerrung durch beliebige Filter (wie "Star"-Anzahl) zu vermeiden.
2. Filterung (Filtering):
   • Ausschluss von Forks, "Toy"-Projekten (zu jung, zu klein < 50 kB) und Projekten ohne Hauptprogrammiersprache.
   • Beschränkung auf statisch typisierte Sprachen (51 Sprachen, darunter C, C++, Java, Go, C#, TypeScript). Dynamisch typisierte Sprachen (wie Python) werden ausgeschlossen, da eine zuverlässige Identifizierung von Gleitkommaoperationen ohne Laufzeitanalyse nicht skalierbar ist.
3. Keyword-basierte Erkennung: Anstatt einen vollständigen Typ-Checker für jede Sprache zu implementieren, wird nach Schlüsselwörtern gesucht (Regex-basiert):
   • Primitive Typen (float, double, real).
   • Transzendente Funktionen (sin, cos, exp).
   • Spezialwerte (nan, inf).
   • Arbiträre Präzision (mpfr).
   • Kommentare und String-Literale werden vor der Analyse entfernt, um False Positives zu minimieren.
4. Deduplizierung: Dateien werden auf Token-Ebene (Bag-of-Words) gehasht, um exakte Duplikate und Token-Reihenfolge-Duplikate zu entfernen.
5. Parsing und Extraktion: Verbleibende Dateien werden mit tree-sitter geparst, um einzelne Funktionen zu extrahieren. Für jede Funktion werden Metriken wie Zeilenzahl, Parameter, Schleifen, Bedingungsanweisungen und Verschachtelungstiefe berechnet.

Das gesamte Framework namens Scyros ist Open-Source und modular aufgebaut.

3. Wichtige Beiträge

• Großangelegte Mining-Methodik: Entwicklung einer vollständig automatisierten Pipeline zur Analyse von Millionen von Repositories, die auf intrinsischen Eigenschaften basiert und Verzerrungen minimiert.
• Quantitative Analyse: Eine umfassende statistische Auswertung von 447.209 zufällig ausgewählten Projekten und 9,9 Millionen extrahierten Funktionen.
• Öffentliches Dataset: Bereitstellung eines Datensatzes mit 10 Millionen realen Gleitkomma-Funktionen aus GitHub, der als Basis für zukünftige Benchmarks dient.
• Challenge Benchmarks: Erstellung eines Sets von 59 selbstständigen C-Benchmarks, die reale Programmiermuster (wie Pointer-Manipulation, Makros, komplexe Abhängigkeiten) abbilden, die von aktuellen Tools oft nicht unterstützt werden.

4. Ergebnisse und Erkenntnisse

Verbreitung (RQ1)

• Gleitkommacode ist extrem weit verbreitet. Mit 95 % Konfidenz enthalten über 62 % der untersuchten Open-Source-Projekte Gleitkommacode.
• Innerhalb eines Projekts ist dieser Code oft in wenigen Dateien konzentriert.

Charakteristika (RQ2)

• Struktur: Reale Gleitkomma-Funktionen sind oft klein (Median ca. 28–61 Wörter), enthalten jedoch häufiger Schleifen (Loops) und Bedingungsanweisungen (Conditionals) als nicht-numerischer Code ähnlicher Größe.
• Kombinationen: Schleifen treten in realen Gleitkomma-Funktionen signifikant häufiger auf als in generischem Code, oft in Kombination mit Bedingungsanweisungen.
• Sprachverteilung: C, C++, Java, TypeScript, C# und Go machen über 92 % des Datensatzes aus.
• Präzision: Single- (32-bit) und Double-Precision (64-bit) dominieren. Half-Precision (16-bit) und Mixed-Precision sind selten.
• Bibliotheken: Die Nutzung der GNU Scientific Library (GSL) ist im Vergleich zu ihrer Häufigkeit in der Literatur extrem gering (< 0,2 % der Dateien).

Repräsentativität von Benchmarks (RQ3)

• FPBench-Vergleich: Die in der Literatur häufig genutzten FPBench-Benchmarks sind nicht repräsentativ für realen Code.
  • Sie enthalten deutlich weniger Bedingungsanweisungen und Schleifen.
  • Transzendente Funktionen sind in FPBench überrepräsentiert.
  • Reale Code-Funktionen sind modularer und nutzen häufiger Hilfsfunktionen und komplexe Kontrollflüsse.
• GSL: Da GSL-Funktionen in realen Projekten kaum vorkommen, sind Benchmarks, die stark auf GSL basieren, für die Evaluierung von Tools, die für allgemeine Anwendungsfälle gedacht sind, wenig aussagekräftig.

5. Signifikanz und Implikationen

Die Studie zeigt, dass die aktuelle Forschung zu Gleitkomma-Analyse-Tools oft an der Realität vorbeigeht.

• Fokusverschiebung notwendig: Da reale Code-Funktionen modular sind und komplexe Kontrollflüsse (Schleifen, Verzweigungen) enthalten, müssen Analyse-Tools diese Features besser unterstützen. Die aktuelle Fokussierung auf isolierte, mathematische Ausdrücke ohne Kontrollfluss ist nicht ausreichend.
• Benchmark-Entwicklung: Das bereitgestellte Dataset und die 59 Challenge Benchmarks bieten eine neue, realistischere Grundlage für die Evaluierung von statischen und dynamischen Analysewerkzeugen.
• Herausforderungen für dynamische Sprachen: Die Studie verdeutlicht, dass eine ähnliche Analyse für dynamisch typisierte Sprachen (wie Python) ohne Laufzeit-Interpretation und Input-Generierung kaum möglich ist, was eine offene Herausforderung für zukünftige Arbeiten darstellt.

Zusammenfassend liefert das Paper den ersten umfassenden Beweis dafür, wie Gleitkommacode in der Praxis tatsächlich aussieht, und fordert die Community auf, ihre Evaluierungsmethoden und Tools an diese Realität anzupassen, anstatt nur an handverlesenen, vereinfachten Beispielen zu forschen.