O que causa erros de arredondamento de ponto flutuante?

Estou ciente de que a aritmética de ponto flutuante tem problemas de precisão. Normalmente, eu os supero alternando para uma representação decimal fixa do número ou simplesmente negligenciando o erro.

No entanto, não sei quais são as causas dessa imprecisão. Por que existem tantos problemas de arredondamento nos números flutuantes?

Isso ocorre porque algumas frações precisam de uma quantidade muito grande (ou mesmo infinita) de locais a serem expressos sem arredondamentos. Isso vale tanto para notação decimal quanto para binário ou qualquer outro. Se você limitar a quantidade de casas decimais a ser usada em seus cálculos (e evitar fazer cálculos em notação de fração), será necessário arredondar até uma expressão simples como 1/3 + 1/3. Em vez de escrever 2/3 como resultado, você teria que escrever 0,33333 + 0,33333 = 0,66666, que não é idêntico a 2/3.

No caso de um computador, o número de dígitos é limitado pela natureza técnica de seus registros de memória e CPU. A notação binária usada internamente adiciona mais algumas dificuldades. Os computadores normalmente não podem expressar números em notação de fração, embora algumas linguagens de programação adicionem essa capacidade, o que permite que esses problemas sejam evitados até certo ponto.

O que todo cientista da computação deve saber sobre aritmética de ponto flutuante

Principalmente, os erros de arredondamento vêm do fato de que o infinito de todos os números reais não pode ser representado pela memória finita de um computador , muito menos por uma pequena fatia de memória, como uma única variável de ponto flutuante , de modo que muitos números armazenados são apenas aproximações de o número que eles devem representar.

Como existe apenas um número limitado de valores que não são uma aproximação e qualquer operação entre uma aproximação e outro número resulta em uma aproximação, os erros de arredondamento são quase inevitáveis .

O importante é perceber quando eles podem causar um problema e tomar medidas para mitigar os riscos .

Além do essencial de David Goldberg , O que todo cientista da computação deve saber sobre aritmética de ponto flutuante (republicado pela Sun / Oracle como um apêndice ao Guia de computação numérica ), mencionado por thorsten , o periódico ACCU Overload teve um excelente série de artigos de Richard Harris sobre o Floating Point Blues .

A série começou com

• Você vai ter que pensar! naSobrecarga nº 99( pdf , p5-10):

A computação numérica tem muitas armadilhas. Richard Harris começa a procurar uma bala de prata.

O dragão do erro numérico geralmente não é despertado de seu sono, mas, se for abordado de maneira incauta, ele ocasionalmente causará danos catastróficos nos cálculos do programador incauto.

Tanto que alguns programadores, por acaso o encontraram nas florestas da aritmética de ponto flutuante da IEEE 754, aconselham seus companheiros a não viajarem nessa terra justa.

Nesta série de artigos, exploraremos o mundo da computação numérica, contrastando a aritmética de ponto flutuante com algumas das técnicas propostas como substitutos mais seguros. Aprenderemos que o território do dragão é de grande alcance e que, em geral, devemos agir com cuidado se temermos sua atenção devastadora.

Richard começa explicando a taxonomia de números reais, racionais, irracionais, algébricos e transcendentais. Ele então explica a representação da IEEE754, antes de passar para o erro de cancelamento e problemas de ordem de execução.

Se você não ler mais do que isso, terá uma excelente base nos problemas associados aos números de ponto flutuante.

Se você quiser saber mais, no entanto, ele continua com

• Por que o ponto fixo não cura o blues de ponto flutuante nasobrecarga 100( pdf , p15-22)
• Por que os Rationals não curam seus blues de ponto flutuante nasobrecarga # 101( pdf , p9-13)
• Por que a álgebra computacional não cura o blues de ponto flutuante nasobrecarga nº 102( pdf , p9-14).
• Por que a aritmética de intervalo não cura o blues de ponto flutuante nasobrecarga 103( pdf , p19-24)

Ele então muda para tentar ajudá-lo a curar seu Calculus Blues

• Por que [inserir o algoritmo aqui] não irá curar seus blues de cálculo nasobrecarga 104( pdf , p22-24).
• Por que as diferenças finitas não curam seus blues de cálculo emsobrecarga 105( pdf , p5-12).
• Por que a aproximação polinomial não cura o blues de cálculo nasobrecarga 106( pdf , p16-25).
• Por que a álgebra computacional não cura o blues de cálculo emsobrecarga 107( pdf , p15-20).

e por último mas não menos importante, existe

• Por que a diferenciação automática não cura o blues de cálculo nasobrecarga 108( pdf , p4-11).

Vale a pena examinar toda a série de artigos e, com 66 páginas no total, ainda são menores que as 77 páginas do artigo de Goldberg .

Embora esta série cubra muito do mesmo terreno, achei-a bastante mais acessível que o artigo de Goldberg . Também achei mais fácil entender as partes mais complexas do artigo depois de ler os artigos anteriores de Richards e, depois desses primeiros artigos, Richard ramifica-se em muitas áreas interessantes não abordadas pelo artigo de Goldberg.

Como assim falou ak mencionado nos comentários:

Como autor desses artigos, gostaria de mencionar que criei versões interativas deles no meu blog www.thusspakeak.com, começando com thusspakeak.com/ak/2013/06 .

Bem, thorsten tem o link definitivo . Eu adicionaria:

Qualquer forma de representação terá algum erro de arredondamento para algum número. Tente expressar 1/3 no ponto flutuante IEEE ou decimal. Nem pode fazê-lo com precisão. Isso vai além da resposta à sua pergunta, mas usei essa regra prática com êxito:

• Armazene os valores inseridos pelo usuário em decimal (porque eles certamente o inseriram em uma representação decimal - muito poucos usuários usarão binário ou hexadecimal). Dessa forma, você sempre tem a representação exata inserida pelo usuário.
• Se você precisar armazenar frações inseridas pelo usuário, armazene o numerador e o denominador (também em decimal)
• Se você possui um sistema com várias unidades de medida para a mesma quantidade (como Celsius / Fahrenheit) e o usuário pode inserir ambos, armazene o valor digitado e as unidades em que inseriram. Não tente converter e salvar como uma única representação, a menos que você possa fazê-lo sem perda de precisão / exatidão. Use o valor e as unidades armazenados em todos os cálculos.
• Armazene valores gerados por máquina no ponto flutuante IEEE (podem ser números gerados por um dispositivo de medição eletrônico, como um sensor analógico com um conversor A / D ou o resultado não arredondado de um cálculo). Observe que isso não se aplica se você estiver lendo um sensor em uma conexão serial e ele já estiver fornecendo o valor em um formato decimal (por exemplo, 18,2 C).
• Armazene totais visíveis ao usuário etc. em decimal (como um saldo de conta bancária). Arredonde adequadamente, mas use esse valor como o valor definitivo para todos os cálculos futuros.

O que parece não ter sido mencionado até agora são os conceitos de um algoritmo instável e um problema mal condicionado . Vou abordar o primeiro primeiro, pois isso parece ser uma armadilha mais frequente para numericistas novatos.

Considere o cálculo dos poderes da proporção áurea (recíproca) φ=0.61803…; Uma maneira possível de fazer isso é usar a fórmula de recursão φ^n=φ^(n-2)-φ^(n-1), começando com φ^0=1e φ^1=φ. Se você executar essa recursão no seu ambiente de computação favorito e comparar os resultados com os poderes avaliados com precisão, encontrará uma erosão lenta de números significativos. Aqui está o que acontece, por exemplo, no Mathematica :

ph = N[1/GoldenRatio];  
Nest[Append[#1, #1[[-2]] - #1[[-1]]] & , {1, ph}, 50] - ph^Range[0, 51]  
{0., 0., 1.1102230246251565*^-16, -5.551115123125783*^-17, 2.220446049250313*^-16, 
-2.3592239273284576*^-16, 4.85722573273506*^-16, -7.147060721024445*^-16, 
1.2073675392798577*^-15, -1.916869440954372*^-15, 3.1259717037102064*^-15, 
-5.0411064211886014*^-15, 8.16837916750579*^-15, -1.3209051907825398*^-14, 
2.1377864756200182*^-14, -3.458669982359108*^-14, 5.596472721011714*^-14, 
-9.055131861349097*^-14, 1.465160458236081*^-13, -2.370673237795176*^-13, 
3.835834102607072*^-13, -6.206507137114341*^-13, 1.004234127360273*^-12, 
-1.6248848342954435*^-12, 2.6291189633497825*^-12, -4.254003796798193*^-12, 
6.883122762265558*^-12, -1.1137126558640235*^-11, 1.8020249321541067*^-11, 
-2.9157375879969544*^-11, 4.717762520172237*^-11, -7.633500108148015*^-11, 
1.23512626283229*^-10, -1.9984762736468268*^-10, 3.233602536479646*^-10, 
-5.232078810126407*^-10, 8.465681346606119*^-10, -1.3697760156732426*^-9, 
2.216344150333856*^-9, -3.5861201660070964*^-9, 5.802464316340953*^-9, 
-9.388584482348049*^-9, 1.5191048798689004*^-8, -2.457963328103705*^-8, 
3.9770682079726053*^-8, -6.43503153607631*^-8, 1.0412099744048916*^-7, 
-1.6847131280125227*^-7, 2.725923102417414*^-7, -4.4106362304299367*^-7, 
7.136559332847351*^-7, -1.1547195563277288*^-6}

O resultado pretendido para φ^41tem o sinal errado e, ainda mais cedo, os valores reais e calculados para φ^39compartilhar sem dígitos em comum ( 3.484899258054952* ^ - 9 for the computed version against the true value7.071019424062048 *^-9). O algoritmo é, portanto, instável, e não se deve usar essa fórmula de recursão em aritmética inexata. Isso se deve à natureza inerente da fórmula de recursão: existe uma solução "decadente" e "crescente" para essa recursão, e tenta-se calcular a solução "decadente" por solução direta quando existe uma solução "crescente" alternativa que está implorando para sofrimento numérico. Portanto, deve-se garantir que seus algoritmos numéricos sejam estáveis.

Agora, sobre o conceito de um problema mal condicionado : embora possa haver uma maneira estável de fazer algo numericamente, pode muito bem ser que o problema que você possui simplesmente não possa ser resolvido pelo seu algoritmo. Isso é culpa do problema em si, e não do método de solução. O exemplo canônico em numérica é a solução de equações lineares envolvendo a chamada "matriz de Hilbert":

A matriz é o exemplo canônico de uma matriz mal condicionada : tentar resolver um sistema com uma matriz Hilbert grande pode retornar uma solução imprecisa.

Aqui está uma demonstração do Mathematica : compare os resultados da aritmética exata

Table[LinearSolve[HilbertMatrix[n], HilbertMatrix[n].ConstantArray[1, n]], {n, 2, 12}]
{{1, 1}, {1, 1, 1}, {1, 1, 1, 1}, {1, 1, 1, 1, 1}, {1, 1, 1, 1, 1, 
  1}, {1, 1, 1, 1, 1, 1, 1}, {1, 1, 1, 1, 1, 1, 1, 1}, {1, 1, 1, 1, 1,
   1, 1, 1, 1}, {1, 1, 1, 1, 1, 1, 1, 1, 1, 1}, {1, 1, 1, 1, 1, 1, 1, 
  1, 1, 1, 1}, {1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1}}

e aritmética inexata

Table[LinearSolve[N[HilbertMatrix[n]], N[HilbertMatrix[n].ConstantArray[1, n]]], {n, 2, 12}]
{{1., 1.}, {1., 1., 1.}, {1., 1., 1., 1.}, {1., 1., 1., 1., 1.},  
  {1., 1., 1., 1., 1., 1.}, {1., 1., 1., 1., 1., 1., 1.}, 
  {1., 1., 1., 1., 1., 1., 1., 1.}, {1., 1., 1., 1., 1., 1., 1., 1., 1.},  
  {1., 1., 1., 0.99997, 1.00014, 0.999618, 1.00062, 0.9994, 1.00031, 
  0.999931}, {1., 1., 0.999995, 1.00006, 0.999658, 1.00122, 0.997327, 
  1.00367, 0.996932, 1.00143, 0.999717}, {1., 1., 0.999986, 1.00022, 
  0.998241, 1.00831, 0.975462, 1.0466, 0.94311, 1.04312, 0.981529, 
  1.00342}}

(Se você testou no Mathematica , notará algumas mensagens de erro avisando sobre o mau condicionamento que aparece.)

Nos dois casos, simplesmente aumentar a precisão não é cura; apenas atrasará a inevitável erosão das figuras.

Isto é o que você pode enfrentar. As soluções podem ser difíceis: pela primeira vez, você volta à prancheta ou vasculha revistas / livros / o que quer que seja para descobrir se alguém encontrou uma solução melhor do que a sua; no segundo, você desiste ou reformula seu problema para algo mais tratável.

Vou deixar você com uma citação de Dianne O'Leary:

A vida pode nos lançar alguns problemas mal condicionados, mas não há boas razões para aceitar um algoritmo instável.

porque os números decimais da base 10 não podem ser expressos na base 2

ou, em outras palavras, 1/10 não pode ser transformado em uma fração com uma potência de 2 no denominador (que é essencialmente o que são os números de ponto flutuante)

Em matemática, existem infinitos números racionais. Uma variável de 32 bits pode ter apenas 2 ³² valores diferentes e uma variável de 64 bits apenas 2 ⁶⁴ valores. Portanto, existem infinitos números racionais que não têm representação precisa.

Poderíamos criar esquemas que nos permitissem representar 1/3 perfeitamente, ou 1/100. Acontece que, para muitos propósitos práticos, isso não é muito útil. Há uma grande exceção: nas finanças, as frações decimais geralmente aparecem. Isso ocorre principalmente porque o financiamento é essencialmente uma atividade humana, não física.

Portanto, geralmente escolhemos usar ponto flutuante binário e arredondamos qualquer valor que não possa ser representado em binário. Mas, nas finanças, às vezes escolhemos o ponto flutuante decimal e arredondamos os valores para o valor decimal mais próximo.

o único "problema de arredondamento" realmente óbvio com números de ponto flutuante em que penso é nos filtros da média móvel:

$$ \ begin {align} y [n] e = \ frac {1} {N} \ sum \ limits_ {i = 0} ^ {N-1} x [ni] \ & = y [n-1] + \ frac {1} {N} (x [n] - x [nN]) \ \ end {align}

Para que isso funcione sem o acúmulo de ruído, você deve certificar-se de que o $ x [n] $ adicionado nas amostras atuais seja exatamente igual ao $ x [nN] $ que você subtrairá $ N $ amostras no futuro. se não for, o que é diferente é um pouco de cocô que fica preso na linha de atraso e nunca sai. isso ocorre porque esse filtro de média móvel é realmente construído com um IIR que possui um pólo marginalmente estável em $ z = 1 $ e um zero que o cancela por dentro. mas, é um integrador e qualquer porcaria que seja integrada e não totalmente removida existirá na soma do integrador para sempre. é aqui que o ponto fixo não tem o mesmo problema que os números de ponto flutuante.