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

Este artigo apresenta o primeiro estudo em grande escala sobre o uso de aritmética de ponto flutuante em repositórios públicos do GitHub para linguagens estaticamente tipadas, analisando milhões de funções para validar benchmarks existentes e fornecer um novo conjunto de dados de 10 milhões de funções para orientar o desenvolvimento e a avaliação de futuras técnicas de raciocínio automatizado.

O essencial

Imagine que você é um arquiteto tentando construir pontes que nunca caem. Para isso, você precisa entender exatamente como a água (os dados) flui e como o vento (os erros de cálculo) age sobre a estrutura.

No mundo do computador, essa "água" são os números de ponto flutuante. São os números que os computadores usam para fazer contas com casas decimais, como 3.14159 ou 0.00001. O problema é que os computadores não são perfeitos: eles arredondam esses números de forma estranha, o que pode causar erros gigantescos em cálculos complexos (como em foguetes espaciais ou diagnósticos médicos).

Os cientistas que criam ferramentas para "consertar" ou verificar esses erros (chamados de ferramentas de raciocínio automático) geralmente testam suas invenções em laboratórios pequenos, usando exemplos práticos que eles mesmos escolheram. É como se o arquiteto testasse sua ponte apenas em uma piscina de plástico, em vez de no mar real.

O que este artigo fez?

Os autores (Andrea, Tobias e Eva) decidiram parar de adivinhar e ir até a fonte. Eles foram até o GitHub (o maior "armazém" de códigos do mundo, onde milhões de programadores guardam seus projetos) e fizeram um censo massivo.

Eles queriam responder a três perguntas simples:

1. Quão comum é esse tipo de código? (É como perguntar: "Quantas casas usam telhas de barro?")
2. Como esse código se parece na vida real? (É uma casa simples de um cômodo ou um castelo com escadas e labirintos?)
3. Os testes que os cientistas usam hoje representam a realidade? (A piscina de plástico é igual ao mar?)

A Grande Descoberta (com analogias)

1. É onipresente: Eles descobriram que mais de 62% dos projetos de código aberto usam esses números. É como descobrir que quase toda casa tem uma torneira. Não é algo raro; é a base de tudo.

2. O Código Real é "Bagunçado" e Complexo:

   • Os testes antigos (FPBench): São como receitas de bolo escritas em um livro de culinária antigo. São limpas, diretas e usam apenas os ingredientes básicos (funções matemáticas puras).
   • O código real: É como a cozinha de uma família grande e barulhenta. Tem panelas, fogões, ingredientes misturados, e o cozinheiro (o programador) pula de uma tarefa para outra.
   • A surpresa: No código real, os programadores usam muito condicionais (se isso acontecer, faça aquilo) e loops (repita isso 10 vezes). Nos testes antigos, essas coisas eram raras. É como se os testes antigos só mostrassem alguém cozinhando em linha reta, enquanto a vida real é cheia de desvios e voltas.

3. O Problema dos "Testes de Laboratório":
   As ferramentas atuais de verificação são ótimas para resolver os problemas "limpos" dos testes antigos, mas elas tropeçam quando veem o código real, cheio de loops e decisões. É como treinar um piloto apenas em simuladores de voo sem turbulência; quando ele vai para o avião real, ele não sabe o que fazer quando o vento muda.

O que eles deixaram para a comunidade?

Em vez de apenas apontar o problema, eles criaram um presente gigante:

• Um banco de dados com 10 milhões de funções reais que usam ponto flutuante. É como se eles tivessem coletado 10 milhões de "receitas reais" de cozinheiros do mundo todo.
• Eles extraíram 59 desafios reais em C (uma linguagem de programação) para que os cientistas possam testar suas ferramentas em situações que realmente importam.

A Lição Final

O artigo diz: "Parem de treinar suas ferramentas apenas em laboratórios perfeitos. Olhem para o código real, que é cheio de loops, decisões e misturas. Se vocês quiserem que suas ferramentas funcionem no mundo real, elas precisam aprender a lidar com a bagunça da vida real, não apenas com a perfeição dos testes antigos."

Eles publicaram tudo o que fizeram (o código, os dados e as ferramentas) para que qualquer pessoa possa baixar, estudar e criar ferramentas melhores que, finalmente, funcionem para os problemas que os desenvolvedores enfrentam todos os dias.

Resumo técnico

Resumo Técnico: Uso de Ponto Flutuante no GitHub

1. Problema e Motivação

O raciocínio sobre aritmética de ponto flutuante é notoriamente difícil devido a erros de arredondamento, valores especiais (como NaN e infinito) e a complexidade de garantir a correção numérica. Embora existam técnicas avançadas de análise estática e dinâmica, bem como ferramentas de reparo de programas, a sua aplicação em código real ainda é limitada.

O problema central identificado pelos autores é a falta de representatividade dos benchmarks atuais. A maioria das ferramentas de verificação e análise é avaliada em conjuntos de benchmarks pequenos, manualmente selecionados (como o FPBench), que muitas vezes consistem em expressões aritméticas isoladas. Não há estudos em larga escala que caracterizem como o código de ponto flutuante é realmente escrito na prática ("código do mundo real"), o que impede o desenvolvimento de ferramentas que atendam às expectativas reais dos usuários quanto a estruturas de controle (loops, condicionais) e complexidade.

2. Metodologia

Os autores desenvolveram uma metodologia de mineração de código em larga escala focada em linguagens estaticamente tipadas no GitHub. A escolha por linguagens estaticamente tipadas deve-se à possibilidade de identificar código de ponto flutuante de forma automatizada e escalável através de anotações de tipo, evitando a necessidade de execução de código (necessária em linguagens dinâmicas para inferir tipos).

O processo segue um pipeline multi-etapa automatizado e reprodutível:

1. Amostragem e Filtragem de Projetos:
   • Amostragem uniforme de repositórios públicos do GitHub via API REST.
   • Exclusão de forks e projetos "triviais" (definidos como: tamanho < 50 kB, idade < 2 meses, ou sem linguagem principal atribuída).
   • Filtragem para reter apenas repositórios que utilizam pelo menos uma das 51 linguagens estaticamente tipadas identificadas (ex: C, C++, Java, Rust, Go, TypeScript, etc.).
2. Identificação de Código de Ponto Flutuante:
   • Download do conteúdo dos repositórios filtrados.
   • Uso de expressões regulares para buscar palavras-chave nos arquivos fonte. As palavras-chave são divididas em quatro categorias:
     • Tipos primitivos (ex: float, double, real).
     • Funções transcendentais (ex: sin, cos, exp).
     • Valores especiais e outras operações (ex: NaN, inf, round, ulp).
     • Precisão arbitrária (ex: mpfr_t).
   • Remoção de comentários e literais de string para reduzir falsos positivos.
3. Deduplicação:
   • Eliminação de arquivos duplicados em nível de tokens (ignorando espaços em branco e ordem de declaração) usando hashes BLAKE3, para evitar viés de medição.
4. Extração e Análise de Funções:
   • Uso da biblioteca de análise sintática tree-sitter para parsear os arquivos e extrair funções individuais.
   • Coleta de métricas por função: número de linhas, palavras, parâmetros, profundidade de aninhamento de loops, condicionais, chamadas de função e contagem de palavras-chave numéricas.

O framework desenvolvido, chamado Scyros, é de código aberto e permite reprodutibilidade total.

3. Principais Contribuições

• Mineração em Larga Escala: A primeira análise empírica em grande escala do uso de aritmética de ponto flutuante em repositórios públicos do GitHub, cobrindo milhões de repositórios e milhões de funções.
• Conjunto de Dados (Dataset): Publicação de um dataset contendo 10 milhões de funções reais de ponto flutuante extraídas do estudo, focado em funções pois a maioria das ferramentas de raciocínio atua nesse nível.
• Benchmark de Desafio (Challenge Benchmarks): Um conjunto de 59 benchmarks C autocontidos, extraídos do dataset, que preservam o contexto real do código (dependências, macros, manipulação de ponteiros), servindo como um alvo mais realista para futuras ferramentas.
• Framework Reutilizável: O código da ferramenta de mineração (Scyros) é disponibilizado para uso em outros estudos empíricos de código.

4. Resultados Chave

• Prevalência (RQ1): Com 95% de confiança, estima-se que mais de 62% dos projetos no GitHub contêm código de ponto flutuante. O código tende a estar concentrado em um pequeno número de arquivos dentro de cada projeto.
• Características do Código (RQ2):
  • Estrutura: As funções de ponto flutuante no mundo real são geralmente pequenas e modulares.
  • Controle de Fluxo: Condicionais são muito comuns (até 63% em Go). Loops são menos frequentes que condicionais, mas quando presentes, quase sempre coexistem com condicionais.
  • Chamadas de Função: Chamadas de função são mais comuns que loops. Curiosamente, chamadas a funções transcendentais (como sin, cos) são menos frequentes do que o esperado; a maioria das funções usa apenas operadores aritméticos básicos.
  • Precisão: float (32-bit) e double (64-bit) dominam. Precisão mista, meia precisão (16-bit) ou precisão quádrupla (128-bit) são raras.
  • Comparação com Benchmarks: O código real difere significativamente do FPBench. O FPBench tem menos condicionais, mais chamadas a funções transcendentais e raramente combina loops com condicionais.
• Representatividade dos Benchmarks (RQ3):
  • Os benchmarks atuais (FPBench e funções da GNU Scientific Library - GSL) não são representativos do código real.
  • O uso de funções da GSL no dataset real é extremamente baixo (< 0,2%), indicando que as ferramentas estão sendo testadas em domínios que não refletem a prática comum.
  • O FPBench alinha-se mais com as capacidades atuais das ferramentas (que têm pouco suporte a loops e condicionais complexos) do que com a realidade do código escrito pelos desenvolvedores.

5. Significado e Implicações

O estudo revela uma lacuna crítica entre a pesquisa em raciocínio sobre ponto flutuante e a prática de engenharia de software:

1. Direcionamento de Pesquisa: As ferramentas atuais estão otimizadas para analisar fragmentos de código isolados e matemáticos, enquanto o código real é modular, rico em controle de fluxo (loops/condicionais) e frequentemente envolve chamadas de função complexas.
2. Necessidade de Novos Benchmarks: Para que as ferramentas de análise estática e dinâmica evoluam, elas precisam ser avaliadas em benchmarks que reflitam a complexidade do mundo real (modularidade, ponteiros, macros, misturas de tipos). O conjunto de 59 benchmarks C extraído pelos autores serve como um ponto de partida para isso.
3. Desafios Futuros: A análise de código de ponto flutuante em linguagens dinamicamente tipadas permanece um desafio aberto, pois a identificação precisa de tipos requer execução de código com dados representativos, algo difícil de escalar.

Em conclusão, o papel demonstra que o código de ponto flutuante é ubíquo, mas estruturalmente diferente do que a literatura acadêmica assume. A comunidade deve migrar para benchmarks baseados em dados reais para desenvolver ferramentas que sejam verdadeiramente úteis para os desenvolvedores.