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

Deze paper presenteert de eerste grootschalige empirische studie naar het gebruik van drijvende-kommaberekeningen in statisch getypeerde GitHub-repositories, waarbij een dataset van 10 miljoen functies wordt vrijgegeven om de representativiteit van bestaande benchmarks te evalueren en toekomstige analyse-technieken te verbeteren.

De kern

De Grote Schatkaart van Wiskundige Code: Een Verkenning van GitHub

Stel je voor dat je een gigantische bibliotheek binnenstapt, de "Bibliotheek van de Wereld", waar elke computerprogramma ter wereld in ligt opgeslagen. In deze bibliotheek zijn er speciale boeken die gaan over drijvende komma-rekenen (floating-point arithmetic). Dat is de manier waarop computers met breuken en decimalen werken, zoals 3.14 of 0.0001.

Het probleem? Het is ontzettend lastig om te weten of die berekeningen in die boeken wel 100% correct zijn. Computers maken soms kleine afrondingsfouten, net als wanneer je geld in je hoofd rekent en een centje verliest. Als die fouten in kritieke software zitten (zoals in een vliegtuig of een medische machine), kan dat rampzalig zijn.

Wetenschappers proberen al jaren nieuwe "rekenregels" (tools) te bedenken om die fouten te vinden. Maar tot nu toe hebben ze die regels getest op een heel klein, speciaal geselecteerd stukje van de bibliotheek. Het was alsof ze alleen maar op de kinderboeken in de bibliotheek testten, terwijl ze eigenlijk wilden weten hoe volwassenen in de echte wereld rekenen.

Wat hebben deze onderzoekers gedaan?

Andrea, Tobias en Eva (de auteurs van dit paper) wilden weten: "Hoe ziet echte, dagelijkse wiskundige code er eigenlijk uit?"

Ze hebben een enorme robot (een software-tool genaamd Scyros) gebouwd die door miljoenen openbare projecten op GitHub (een soort GitHub voor programmeurs) heeft gekeken. Ze hebben gekeken naar talen waar de programmeur zelf moet zeggen wat voor soort getal hij gebruikt (zoals C++, Java en Go), omdat dat makkelijker is om automatisch te scannen.

De Grote Ontdekkingen (in simpele taal):

1. Het is overal:
   Net als dat bijna iedereen wel eens koffie drinkt, gebruiken bijna alle grote softwareprojecten drijvende komma-getallen. Ze schatten dat meer dan 62% van alle projecten dit gebruiken. Het is dus niet iets voor alleen maar ruimtevaart-ingenieurs; het zit in alles.

2. De "Kinderboeken" vs. De "Echte Wereld":
   De onderzoekers vergeleken de bestaande testboeken (de benchmarks die wetenschappers nu gebruiken) met de echte code die ze vonden.

   • De testboeken (FPBench): Dit zijn vaak simpele, geïsoleerde rekensommen. Ze lijken op een oefening in een wiskundehoofdstuk: "Bereken de sinus van 30 graden." Ze hebben weinig vertakkingen (als-dit-dan-dat) en geen lussen (herhalingen).
   • De echte code: Dit is veel rommeliger en complexer. Echte code zit vol met if-statements (als dit gebeurt, doe dat dan) en loops (doe dit steeds opnieuw).
   • De les: De huidige testtools zijn getest op simpele, geïsoleerde sommen. Maar in de echte wereld werken die tools vaak niet goed omdat ze niet gewend zijn aan die rommelige, complexe structuren. Het is alsof je een auto test op een rechte racebaan, maar de auto moet eigenlijk door een drukke stad met stoplichten en bochten rijden.

3. De "GSL" is een mythe:
   In de wetenschap wordt vaak gesproken over de "GNU Scientific Library" (een soort standaardpakket met wiskundige functies) als voorbeeld. De onderzoekers vonden dat deze library in de echte wereld bijna nooit wordt gebruikt. Het is alsof je denkt dat iedereen in Nederland "De Telegraaf" leest, terwijl blijkt dat mensen vooral online nieuws lezen. De tools die gebaseerd zijn op die library missen dus de echte praktijk.

4. Kleine stukjes, grote impact:
   De meeste wiskundige code zit in kleine, zelfstandige stukjes (functies), niet in één gigantisch, onbegrijpelijk blok. Dit is goed nieuws! Het betekent dat we tools kunnen bouwen die zich focussen op die kleine stukjes, zolang ze maar goed kunnen omgaan met de "verwarring" (de loops en if-statements) eromheen.

Wat hebben ze gedaan met deze kennis?

Ze hebben niet alleen gekeken, ze hebben ook iets teruggegeven aan de gemeenschap:

• Ze hebben een enorme dataset vrijgegeven met 10 miljoen echte wiskundige functies.
• Ze hebben 59 nieuwe testcases gemaakt (de "Challenge Benchmarks"). Deze zijn niet gemaakt door wetenschappers in een lab, maar zijn echt uit de wereld gehaald. Ze bevatten de echte rommel: pointers, macro's en complexe logica.

Conclusie: Waarom is dit belangrijk?

Stel je voor dat je een nieuwe bril ontwerpt om slecht zicht te corrigeren. Als je die bril alleen test op een witte muur met een zwart puntje, denk je dat hij perfect werkt. Maar als je hem op straat probeert, met bewegende auto's en regen, werkt hij misschien niet.

Deze paper zegt: "Stop met testen op de witte muur. Kijk eens naar de echte, rommelige straat."

Door te kijken naar hoe programmeurs echt werken, kunnen we betere tools bouwen die niet alleen in theorie werken, maar ook in de praktijk. Ze hebben de kaart getekend van het echte landschap, zodat de volgende generatie wetenschappers niet meer verdwaalt in een fantasiewereld, maar de echte problemen oplost.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het paper "Floating-Point Usage on GitHub: A Large-Scale Study of Statically Typed Languages" in het Nederlands.

Probleemstelling

Redeneren over zwevendekommabewerkingen (floating-point arithmetic) is berucht moeilijk vanwege afrondingsfouten en speciale waarden zoals NaN en oneindigheid. Hoewel er aanzienlijke vooruitgang is geboekt met statische en dynamische analyse-technieken en programmareparatie, is het nog steeds onduidelijk hoe relevant deze technieken zijn voor echt bestaande code.

De huidige onderzoeken en hulpmiddelen worden vaak geëvalueerd op handmatig geselecteerde benchmarks (zoals FPBench). Het is echter onbekend of deze benchmarks representatief zijn voor de complexiteit, grootte en het gebruik van programmeerconstructies in "real-world" software. Er ontbreekt een grootschalig empirisch onderzoek dat inzicht geeft in hoe zwevendekommabewerkingen daadwerkelijk worden gebruikt in open-source projecten.

Methodologie

De auteurs hebben een volledig geautomatiseerde, reproduceerbare pipeline ontwikkeld (het framework Scyros) om zwevendekommacode te analyseren in miljoenen GitHub-repositories. Om schaalbaarheid te garanderen, beperkten ze zich tot statisch getypeerde talen, omdat typeannotaties essentieel zijn om zwevendekommabewerkingen betrouwbaar te identificeren zonder de code uit te voeren.

De pipeline bestaat uit de volgende stappen:

1. Steekproef en Filtering: Uniforme steekproef van GitHub-repositories via de REST API. Filtering op intrinsieke eigenschappen (grootte > 50 kB, leeftijd > 2 maanden, geen forks) om "toy"-projecten en duplicaten te vermijden.
2. Taalselectie: Selectie van repositories die code bevatten in een van de 51 gedefinieerde statisch getypeerde talen (o.a. C, C++, Java, Go, C#, TypeScript).
3. Keyword-Filtering: Identificatie van bestanden met zwevendekommabewerkingen door te zoeken naar specifieke keywords (bijv. types zoals float, double, wiskundige functies zoals sin, cos, en speciale waarden zoals NaN). Dit gebeurt via reguliere expressies.
4. Deduplicatie: Verwijdering van token-level duplicaten (bestanden die identiek zijn na het negeren van witruimte en volgorde) om meetbias te voorkomen.
5. Parsing en Functie-extractie: Gebruik van de taal-agnostische parser Tree-sitter om bestanden te parsen, commentaren te verwijderen (om false positives te voorkomen) en individuele functies te extraheren.
6. Statistische Analyse: Extractie van metadata per functie (aantal regels, woorden, parameters, aanwezigheid van loops, conditionals, functieoproepen, en diepte van nesting).

Belangrijkste Bijdragen

1. Grootschalige Mining: Een nieuwe, volledig geautomatiseerde methode om zwevendekommagebruik te detecteren in statisch getypeerde code op schaal van miljoenen repositories.
2. Dataset: Publicatie van een dataset van 10 miljoen real-world zwevendekommabewerkingen (functies) geëxtraheerd uit GitHub.
3. Benchmark-Validatie: Een kwantitatieve vergelijking tussen bestaande literatuur-benchmarks (FPBench) en de gevonden real-world code.
4. Challenge Benchmarks: Een case study waarbij 59 zelfstandige, compileerbare C-benchmarks zijn gegenereerd die realistische patronen (zoals loops, conditionals en pointer-manipulatie) bevatten die vaak ontbreken in bestaande benchmarks.

Resultaten

De analyse van 447.209 projecten levert de volgende inzichten op:

• Prevalentie (RQ1): Zwevendekommabewerkingen zijn extreem wijdverspreid. Met 95% zekerheid bevat meer dan 62% van de open-source projecten zwevendekommacode. De code is echter vaak geconcentreerd in een klein aantal bestanden binnen een project.
• Kenmerken van Code (RQ2):
  • Structuur: Real-world functies zijn over het algemeen klein (mediaan ~30 woorden), maar bevatten vaker loops en conditionals dan benchmarks suggereren.
  • Constructies: In real-world code komen loops en conditionals vaak samen voor (bijv. 69-87% van de functies met een loop bevat ook een conditional). In benchmarks zoals FPBench zijn deze constructies significant ondervertegenwoordigd.
  • Functieoproepen: Fictieve bibliotheekfuncties (transcendentale functies) komen minder vaak voor dan in benchmarks, terwijl functieoproepen in het algemeen zeer frequent zijn.
  • Talen: C, C++, Java, TypeScript, C# en Go vormen samen meer dan 92% van de dataset.
  • Precisie: Enkelvoudige (32-bit) en dubbele (64-bit) precisie domineren. Mixed-precision en hogere precisies (128-bit) zijn zeldzaam.
• Representativiteit van Benchmarks (RQ3):
  • FPBench: Deze benchmarks zijn representatief voor het aantal parameters, maar niet voor de complexiteit. Ze bevatten te veel transcendentale functies en te weinig loops/conditionals. Ze lijken meer op de beperkingen van huidige analyse-tools dan op wat ontwikkelaars schrijven.
  • GNU Scientific Library (GSL): Functies uit de GSL, die vaak in de literatuur worden gebruikt voor evaluatie, komen extreem zelden voor in real-world code (< 0,2% van de bestanden).

Significantie en Conclusie

Dit onderzoek toont aan dat de huidige benchmarks voor zwevendekommabewerkingen niet representatief zijn voor de praktijk. Bestaande tools zijn vaak geoptimaliseerd voor kleine, geïsoleerde wiskundige uitdrukkingen zonder complexe controle-flow.

De studie concludeert dat toekomstige analyse-tools en benchmarks zich moeten richten op:

1. Modulariteit: Het analyseren van vele kleine, onderling verbonden functies in plaats van monolithische kernels.
2. Controle-flow: Het vermogen om om te gaan met loops en conditionals, die in real-world code de norm zijn.
3. Realistische Patronen: Het gebruik van benchmarks die afgeleid zijn van echte codebases, inclusief patronen zoals pointer-manipulatie en type-casting, zoals geïllustreerd in de gegenereerde C-benchmarks.

De gepubliceerde dataset en tools bieden een fundamentele basis voor het ontwikkelen van robuustere, schaalbare en praktijkgerichte hulpmiddelen voor numerieke verificatie en reparatie.