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

Questo studio empirico su larga scala analizza l'uso dell'aritmetica in virgola mobile in milioni di repository GitHub per linguaggi staticamente tipizzati, fornendo un dataset di 10 milioni di funzioni reali e valutando la rappresentatività degli attuali benchmark rispetto al codice di produzione.

L'essenziale

Immagina di essere un architetto che deve costruire ponti incredibilmente sicuri. Per farlo, hai bisogno di capire esattamente come si comportano i materiali reali (acciaio, cemento) quando vengono sottoposti a stress, pioggia o salsedine.

Fino a poco tempo fa, gli ingegneri del software che lavorano con i numeri decimali (quelli con la virgola, usati per calcoli scientifici, grafica 3D, intelligenza artificiale) stavano costruendo i loro "ponti" basandosi su campioni di materiali che non assomigliavano affatto alla realtà. Usavano solo piccoli blocchi di metallo perfetti e lisci, mentre nel mondo reale i materiali sono arrugginiti, piegati e pieni di buchi.

Ecco di cosa parla questo studio, tradotto in parole semplici:

1. Il Problema: I "Campioni" Falsi

Gli scienziati che creano strumenti per verificare se i calcoli dei computer sono corretti (per evitare che un razzo esploda o un farmaco sia dosato male) usano dei test standard (chiamati benchmark).
Il problema? Questi test sono come se provassimo a testare un'auto da corsa facendola guidare solo su un tapis roulant in laboratorio. Sono piccoli, controllati e perfetti. Ma nella vita reale, le auto guidano su strade piene di buche, curve improvvise e traffico.
Gli autori si sono chiesti: "I nostri test assomigliano davvero a come gli sviluppatori scrivono il codice oggi?"

2. L'Esperimento: Una Grande Ricetta di Cucina

Per rispondere, Andrea, Tobias ed Eva hanno deciso di fare un'ispezione di massa. Hanno guardato milioni di progetti ospitati su GitHub (il "supermercato" dove gli sviluppatori mettono il loro codice).

Hanno usato un approccio intelligente:

• Non hanno guardato tutto: Era troppo. Hanno preso un campione casuale, come se assaggiassimo un cucchiaino di zuppa per capire se è salata, invece di berne tutta la pentola.
• Hanno filtrato il "rumore": Hanno scartato i progetti "finti" (quelli creati per compiti scolastici o non aggiornati da anni) e si sono concentrati solo sui linguaggi di programmazione che hanno un "etichetta" chiara sui tipi di dati (linguaggi staticamente tipizzati).
• La caccia alle parole chiave: Invece di leggere ogni singola riga di codice (impossibile!), hanno cercato parole specifiche come float, double, sin, cos, NaN (Not a Number). È come cercare la parola "zucchero" in un milione di ricette per capire quanto è dolce la dieta mondiale.

3. Le Scoperte: La Realtà è Diversa

Ecco cosa hanno scoperto, usando delle metafore:

• I numeri decimali sono ovunque: Hanno scoperto che oltre il 62% dei progetti software contengono calcoli con la virgola. È come scoprire che quasi ogni casa ha una cucina: è fondamentale.
• I test attuali sono "troppo puliti": I test usati finora (come FPBench) assomigliano a ricette scritte da un robot: poche variabili, niente imprevisti.
  • Nel codice reale, invece, i calcoli sono spesso mescolati a decisioni (se piove, prendi l'ombrello) e ripetizioni (fai questo 100 volte).
  • I test attuali hanno pochissime "decisioni" (condizioni) e poche "ripetizioni" (cicli), mentre nel codice vero queste cose sono ovunque.
• Le librerie famose sono meno usate di quanto si pensi: Molti testi usano funzioni di una libreria scientifica famosa (GSL) come esempio. Lo studio ha scoperto che nel mondo reale, queste funzioni sono usate raramente. È come se tutti i manuali di cucina dicessero "usa il sale marino", ma nella realtà la gente usasse quasi sempre il sale grosso.
• I codici sono piccoli e modulari: Contrariamente all'idea di enormi blocchi di calcolo matematico, il codice reale è fatto di tantissime piccole funzioni che si chiamano a vicenda. È come un'orchestra dove ogni musicista suona una nota breve, non un solista che suona un'opera intera da solo.

4. La Soluzione: Una Nuova "Cassetta degli Attrezzi"

Gli autori non si sono limitati a criticare i vecchi test. Hanno creato qualcosa di nuovo:

1. Un Dataset Gigante: Hanno estratto 10 milioni di funzioni reali dal codice pubblico. È come avere un archivio infinito di ricette vere, non quelle di scuola.
2. Nuovi Test Sfida: Hanno creato 59 nuovi "test" in linguaggio C, presi direttamente da questo archivio. Questi test sono "sporchi", complessi e reali. Contengono trucchi, loop e decisioni che i vecchi strumenti di verifica spesso non riescono a gestire.

Perché è importante?

Immagina che i vecchi test fossero come una guida per imparare a guidare su un campo da golf vuoto. I nuovi test di questo studio ti fanno guidare nel traffico di Roma alle 17:00.

Se vogliamo che i computer siano sicuri quando calcolano cose importanti (dai voli spaziali all'intelligenza artificiale), dobbiamo smettere di allenarci su campi da golf e iniziare a praticare nel traffico reale. Questo studio ci dà la mappa per farlo.

In sintesi: Gli autori hanno guardato il "mondo reale" del codice, hanno scoperto che i nostri vecchi test erano troppo semplificati, e hanno creato nuovi, veri e propri "palestre" per addestrare gli strumenti di sicurezza informatica a gestire la complessità della vita vera.

Sommario tecnico

Ecco un riassunto tecnico dettagliato del paper "Floating-Point Usage on GitHub: A Large-Scale Study of Statically Typed Languages" in italiano.

1. Il Problema

La verifica e l'analisi automatica dell'aritmetica in virgola mobile (floating-point) sono compiti notoriamente difficili a causa degli errori di arrotondamento e dei valori speciali (come NaN e Inf). Sebbene esistano tecniche di analisi statica e dinamica, la loro rilevanza per il codice reale è limitata.
Il problema centrale identificato dagli autori è la mancanza di comprensione su come viene effettivamente utilizzato il codice in virgola mobile nel mondo reale. La ricerca attuale si basa spesso su benchmark "a mano" (hand-picked), come la suite FPBench, che sono piccoli, isolati e selezionati per dimostrare le capacità attuali degli strumenti, piuttosto che per riflettere la complessità del codice prodotto dagli sviluppatori. Non è chiaro quanto questi benchmark siano rappresentativi del codice reale in termini di dimensione, strutture di controllo (loop, condizionali) e frequenza d'uso delle librerie.

2. Metodologia

Per colmare questo divario, gli autori hanno condotto il primo studio empirico su larga scala sull'uso dell'aritmetica in virgola mobile nei repository pubblici di GitHub.

• Ambito di studio: Si sono limitati ai linguaggi tipizzati staticamente (51 linguaggi inclusi, come C, C++, Java, Rust, Go, TypeScript). Questo permette di identificare l'uso dei tipi in virgola mobile tramite annotazioni di tipo senza dover eseguire il codice o eseguire inferenze di tipo complesse, rendendo l'analisi scalabile a milioni di repository.

• Pipeline di estrazione dei dati:

  1. Campionamento: Campionamento uniforme di milioni di ID di repository tramite GitHub REST API.
  2. Filtraggio dei progetti: Eliminazione dei fork, progetti "toy" (troppo piccoli, <50kB), progetti inattivi (<2 mesi) e progetti senza linguaggio principale.
  3. Filtraggio linguistico: Selezione dei progetti che contengono almeno uno dei 51 linguaggi tipizzati staticamente supportati.
  4. Ricerca per parole chiave: Download del codice e ricerca di parole chiave specifiche (tipi primitivi come float, double; funzioni trascendentali come sin, exp; valori speciali come NaN; funzioni a precisione arbitraria).
  5. Deduplicazione: Rimozione dei duplicati a livello di token (usando hash BLAKE3 su "bag-of-words") per evitare bias dovuti al codice clonato.
  6. Parsing ed estrazione: Utilizzo della libreria tree-sitter per parsare i file, rimuovere commenti e stringhe letterali (per ridurre i falsi positivi) ed estrarre le singole funzioni.
  7. Analisi strutturale: Per ogni funzione estratta, vengono calcolate metriche come numero di righe, parametri, presenza di loop, condizionali, chiamate a funzione e profondità di annidamento.

• Strumento: Hanno sviluppato Scyros, un framework open-source in Rust per lo studio su larga scala del codice, progettato per essere riproducibile e modulare.

3. Contributi Chiave

1. Metodologia di Mining su Larga Scala: Un approccio automatizzato e riproducibile per identificare e analizzare l'uso della virgola mobile in milioni di progetti, scalabile a diversi linguaggi tipizzati staticamente.
2. Dataset Pubblico: Rilascio di un dataset contenente 10 milioni di funzioni reali in virgola mobile estratte da GitHub, con metadata dettagliati sulla loro struttura.
3. Analisi Quantitativa: La prima caratterizzazione statistica dell'uso reale della virgola mobile, confrontata con i benchmark esistenti.
4. Challenge Benchmarks: Estrazione e pubblicazione di 59 benchmark C auto-contenuti e realistici, derivati dal dataset, per testare gli strumenti di ragionamento sulla virgola mobile.

4. Risultati Principali

Prevalenza (RQ1)

• L'aritmetica in virgola mobile è estremamente diffusa: con un livello di confidenza del 95%, oltre il 62% dei progetti analizzati contiene codice in virgola mobile.
• Tuttavia, all'interno di un progetto, questo codice tende a essere concentrato in un numero ristretto di file.

Caratteristiche del Codice (RQ2)

• Dimensione: La maggior parte delle funzioni è piccola (mediana di circa 28-61 parole a seconda del linguaggio).
• Struttura di Controllo:
  • Le chiamate a funzione sono molto comuni (presenti nella maggior parte delle funzioni).
  • I condizionali sono frequenti (es. 63% in Go).
  • I loop sono meno frequenti delle chiamate a funzione, ma quando presenti, sono quasi sempre accompagnati da condizionali.
  • Confronto con il codice non numerico: A parità di dimensione, le funzioni in virgola mobile hanno una probabilità significativamente più alta di contenere loop rispetto al codice generico.
• Precisione: I tipi a singola precisione (32-bit) e doppia precisione (64-bit) dominano. L'uso di precisione mista, precisione ridotta (16-bit) o precisione quadrupla (128-bit) è raro.
• Librerie: L'uso di funzioni della GNU Scientific Library (GSL) è estremamente raro (<0.2% dei file), contraddicendo l'uso frequente di GSL nei benchmark accademici.

Rappresentatività dei Benchmark (RQ3)

• FPBench non è rappresentativo: I benchmark FPBench differiscono significativamente dal codice reale:
  • Contengono molte più funzioni trascendentali (es. sin, cos) rispetto al codice reale.
  • Contengono molto meno condizionali e combinazioni di loop/condizionali/chiamate.
  • Sono spesso isolati, mentre il codice reale è modulare e dipende da altre funzioni.
• I benchmark attuali riflettono più le capacità attuali degli strumenti di analisi (che faticano con loop e condizionali) che le aspettative degli utenti su cosa gli strumenti dovrebbero analizzare.

5. Significato e Implicazioni

• Ridefinizione dei Benchmark: Lo studio dimostra che i benchmark attuali sono "facili" per gli strumenti ma non realistici. Per progredire, la ricerca deve spostarsi verso benchmark che includano strutture di controllo complesse (loop, condizionali) e modularità.
• Sviluppo di Strumenti: Gli strumenti di analisi statica e dinamica devono migliorare il supporto per:
  • La combinazione di loop e condizionali.
  • L'analisi modulare (chiamate a funzioni esterne).
  • La gestione di contesti reali (non solo espressioni matematiche isolate).
• Sfide per i Linguaggi Dinamici: L'approccio basato su parole chiave e tipi funziona bene per i linguaggi statici, ma non è direttamente applicabile ai linguaggi dinamici (come Python) senza esecuzione del codice e risoluzione delle dipendenze, un'area lasciata per lavori futuri.

In sintesi, il paper fornisce una base empirica solida per guidare lo sviluppo futuro degli strumenti di verifica numerica, spostando il focus da espressioni matematiche isolate a funzioni reali, modulari e strutturalmente complesse.