 |
| Bellacosa Mainframe uso de ponto flutuante em cobol |
☕🔥 Por que quase ninguém usa ponto flutuante em COBOL?
Essa pergunta parece simples… mas toca em um dos temas mais profundos da arquitetura dos sistemas corporativos.A verdade é que:
O COBOL foi criado para o mundo financeiro.
E o mundo financeiro NÃO tolera erro decimal.
Enquanto linguagens científicas valorizam amplitude numérica e velocidade matemática, o COBOL nasceu em bancos, seguradoras, folha de pagamento, contabilidade e governo — ambientes onde 1 centavo errado pode virar um desastre jurídico, contábil e operacional.
E é exatamente aí que o ponto flutuante começa a se tornar um problema.
O QUE É PONTO FLUTUANTE?
Quando falamos em COMP-1 e COMP-2, estamos falando de números armazenados em formato binário exponencial, parecido com IEEE Floating Point usado em C, Java, Python e hardware matemático.
Em vez de armazenar:
50000.00
o computador guarda algo próximo de:
mantissa × base^expoente
Exemplo conceitual:
5.000000 × 10^4
Isso permite:
✅ números gigantescos
✅ cálculos rápidos
✅ grande amplitude matemática
✅ excelente uso científico
Mas cria um problema clássico:
❌ muitos decimais NÃO existem exatamente em binário.
O GRANDE VILÃO: BINÁRIO NÃO REPRESENTA DECIMAL DIREITO
O mesmo problema ocorre em quase TODAS as linguagens.
Por exemplo:
0.1 + 0.2
Em várias linguagens o resultado interno vira:
0.30000000000000004
Porque:
0.1 decimal
não possui representação binária exata.
É parecido com tentar representar:
1/3
em decimal.
Você obtém:
0.333333333333...
Ou seja:
decimal sofre para representar certas frações binárias
binário sofre para representar certas frações decimais
E dinheiro é DECIMAL.
POR QUE ISSO É UM PESADELO EM SISTEMAS FINANCEIROS?
Imagine:
juros compostos
imposto
IOF
parcelamento
amortização
câmbio
atualização monetária
Agora imagine isso sendo executado:
milhões de vezes
durante décadas
em batchs gigantescos
conciliando bilhões
Se cada operação errar:
0.0000001
o erro acumulado explode.
Seu exemplo mostrou isso perfeitamente.
ANALISANDO O EXEMPLO
Seu programa é brilhante porque demonstra algo MUITO real:
perform 5000000 times
add 0,01 to ponto-fixo
add 0,01 to float-curto
add 0,01 to float-longo
end-perform
Teoricamente:
5.000.000 × 0,01 = 50.000,00
O decimal fixo (COMP-3) chega exatamente nisso.
Mas observe os floats:
Float Curto..: 52.159,66
Float Longo..: 49.999,99
O COMP-1 ficou MAIS DE DOIS MIL REAIS errado.
Isso assusta muita gente iniciante.
Mas faz total sentido tecnicamente.
POR QUE O COMP-1 ERRA TANTO?
Porque ele possui apenas cerca de:
7 dígitos de precisão
E seu processamento acumulou arredondamentos continuamente.
O computador não está “errando”.
Ele está armazenando aproximações sucessivas.
Exemplo simplificado:
0,01
internamente pode virar:
0,0099999997
ou:
0,0100000003
Após milhões de somas:
💥 divergência enorme.
O COMP-2 É MELHOR… MAS AINDA NÃO É CONFIÁVEL
O COMP-2 usa 8 bytes.
Possui aproximadamente:
15~16 dígitos de precisão
Por isso o erro final ficou pequeno:
delta +0000000000000,000013
Mas para o mercado financeiro:
“quase certo” ainda significa ERRADO.
Em banco:
0,01 errado é incidente
0,001 errado é problema
0,000013 errado pode quebrar conciliação
Mainframe não trabalha com “praticamente”.
Ele trabalha com:
✅ exatidão auditável
✅ rastreabilidade
✅ conformidade legal
✅ precisão contábil
POR ISSO O COBOL AMA COMP-3
O verdadeiro rei do mundo financeiro é:
PACKED DECIMAL
ou:
COMP-3
Porque ele armazena os dígitos DECIMAIS diretamente.
Exemplo:
PIC S9(7)V99 COMP-3
Armazena:
12345,67
como decimal compactado.
Sem conversão binária aproximada.
Resultado:
✅ precisão absoluta
✅ cálculos exatos
✅ sem erro acumulativo
✅ ideal para dinheiro
O QUE O COMP-3 SACRIFICA?
Ele perde em:
velocidade matemática bruta
amplitude numérica
cálculos científicos
Mas ganha no que importa ao negócio:
✅ confiabilidade financeira
E essa foi a prioridade histórica do COBOL.
O HARDWARE IBM FOI FEITO PARA ISSO
Aqui entra algo MUITO interessante da arquitetura IBM Z.
Os mainframes possuem instruções de hardware específicas para decimal packed.
Não é “emulação lenta”.
O próprio processador IBM Z possui:
decimal arithmetic instructions
packed decimal engine
decimal floating point support (mais moderno)
instruções financeiras especializadas
Ou seja:
o hardware foi literalmente desenhado para contabilidade.
Isso é um diferencial gigantesco do mundo mainframe.
POR QUE LINGUAGENS MODERNAS USAM FLOAT O TEMPO TODO?
Porque muitas aplicações modernas:
gráficos
IA
jogos
física
machine learning
rendering
estatística
não precisam de precisão decimal absoluta.
Para um jogo:
x = 14.99999997
não importa.
Para uma animação:
0.3000000004
é irrelevante.
Já num banco:
💀 isso vira reconciliação quebrada.
COBOL E O TRAUMA HISTÓRICO DOS CENTAVOS
Existe uma regra não escrita no mundo corporativo:
“Nunca use float para dinheiro.”
Isso veio de décadas de incidentes reais.
Sistemas antigos em C, Java e VB frequentemente causavam:
divergência bancária
erros de fechamento
problemas fiscais
falhas de arredondamento
diferenças em lote
Por isso Java criou:
BigDecimal
C# criou:
decimal
Python recomenda:
Decimal
Todos tentando reproduzir a filosofia do COBOL.
O PARADOXO
Curiosamente:
o COBOL estava CERTO desde os anos 60.
Enquanto outras linguagens correram atrás depois.
O modelo COBOL de:
✅ decimal fixo
✅ precisão absoluta
✅ representação financeira
✅ aritmética decimal
era exatamente o que sistemas corporativos precisavam.
MAS ENTÃO COMP-1 E COMP-2 SERVEM PARA QUÊ?
Eles existem principalmente para:
1. Aplicações científicas
Exemplo:
engenharia
estatística
meteorologia
cálculos atuariais
física
2. Integração com outras linguagens
Exemplo:
C
Java JNI
APIs numéricas
cálculos externos
3. Processamento matemático de alta amplitude
Exemplo:
6.022 × 10^23
número de Avogadro.
Impossível com decimal fixo convencional.
4. Dados vindos de hardware externo
Exemplo:
sensores
telemetria
cálculos industriais
O COBOL MODERNO E DECIMAL FLOATING POINT
Aqui entra algo avançado.
Os IBM Z modernos suportam:
Decimal Floating Point (DFP)
IEEE 754R decimal
hardware decimal floating
Isso tenta unir:
✅ amplitude
✅ velocidade
✅ precisão decimal
Mas mesmo assim:
em aplicações financeiras clássicas o COMP-3 continua soberano.
Porque ele é previsível, auditável e historicamente confiável.
UM DETALHE IMPORTANTE: ORDEM DAS OPERAÇÕES
Com float, até a ordem das somas pode mudar o resultado.
Exemplo:
(A + B) + C
pode ser diferente de:
A + (B + C)
Isso acontece por arredondamentos intermediários.
Em processamento paralelo isso vira um inferno.
Já decimal fixo reduz drasticamente esse problema.
OUTRA QUESTÃO CRÍTICA: COMPARAÇÃO
Em float:
IF VALOR = 0.3
pode falhar.
Porque internamente:
0.30000000000004
Isso causa bugs clássicos.
Por isso sistemas científicos usam tolerância:
ABS(A-B) < epsilon
Mas imagine isso em contabilidade.
💀 inviável.
O QUE UM PROGRAMADOR MAINFRAME APRENDE CEDO
O desenvolvedor COBOL veterano aprende rapidamente:
✅ dinheiro → COMP-3
✅ contador → COMP
✅ flags → DISPLAY/COMP
✅ float → evitar
É quase uma cultura histórica do mundo IBM.
RESUMO FINAL
COMP-1 / COMP-2 são ótimos para:
✅ ciência
✅ estatística
✅ amplitude numérica
✅ interoperabilidade
✅ cálculos matemáticos extremos
Mas são perigosos para:
❌ dinheiro
❌ contabilidade
❌ juros
❌ impostos
❌ conciliação
❌ sistemas bancários
A GRANDE LIÇÃO
O COBOL não evita ponto flutuante por limitação.
Ele evita porque:
precisão financeira vale mais que velocidade matemática.
E essa decisão arquitetural ajudou o mainframe a sustentar por décadas:
bancos
bolsas de valores
cartões
previdência
sistemas fiscais
compensação bancária
processamento financeiro global
com um nível de confiabilidade que poucas plataformas conseguiram igualar.
