Por que a exatidão do módulo de ponto flutuante é importante?

Atualmente, a maioria dos dialetos do Smalltalk implementa um módulo flutuante inexato e ingênuo (fmod / restante).
Eu apenas mudei isso para melhorar o Squeak / Pharo e, eventualmente, outra aderência do Smalltalk aos padrões (IEEE 754, ISO / IEC 10967), como já fiz em outras operações de ponto flutuante de última geração.

No entanto, para a adoção dessas mudanças, prevejo que a adesão ao padrão não será suficiente para convencer meus colegas, portanto, explicar em quais circunstâncias essa exatidão realmente importaria me ajudaria muito. Não consegui encontrar um bom exemplo sozinho até agora.

Alguém aqui sabe por que / quando / onde (IOW em que algoritmo) tal exatidão de módulo importaria?

arithmetic floating-point

— aka.nice
fonte

Eu acho que você pode obter melhores respostas sobre Ciência da Computação, pois essas questões são mais importantes em seu (sub-) domínio. De qualquer forma, a pergunta é ontopica aqui e você deve responder aos respondentes alguns dias antes da publicação.

— Raphael

Eu vi o código contando com a exatidão do fmod / modf, o que me fez estremecer, mas a possibilidade de uma linguagem ousar implementar um módulo ingênuo de ponto flutuante inexato parece ainda mais assustadora. Código de exemplo: (1) Pegue o restante. (2) Pare se for zero. (3) Multiplique por 2 e vá para (1). Pode-se fazer algum trabalho útil durante esse processo, mas o ponto crucial é que o término desse processo depende da exatidão do restante e da multiplicação por 2. Não tenho certeza se devo dar uma resposta mais completa aqui, porque a Ciência da Computação parece mais apropriada para esta pergunta.

— Thomas Klimpel

Um palpite: normalizando a entrada de uma função trigonométrica.

— Paul A. Clayton

@ThomasKlimpel Estou interessado em encontrar referências. Observe que o resto ingênuo é definido como (x - ((y / x) truncado * x)) com IEEE arredondado para as operações pares mais próximas, podemos provar que exatoRem (x, y) == 0 => naiveRem (x, y) == 0. O problema é o contrário - divisão exata exata falsa positiva - como ingênuoRem (4.0,0.1) == 0.0 que infelizmente se encaixa em expectativas ingênuas em muitos casos!

— aka.nice

@ PaulA.Clayton sim, para seno em graus, talvez ... Embora, meu palpite é que rem ingênuo funciona igualmente bem como rem exato até aprox. 1e16 graus porque 360 possui apenas um intervalo de 6 bits definido e porque a divisão por 360 parece nunca arredondar para predecessores de múltiplos de 360 ... Para radianos, uma biblioteca decente requer precisão múltipla, faz um remédio exato limitado à precisão dupla realmente ajudar nesse caso?

— aka.nice

Observe que a implementação inexata de ponto flutuante afeta o clima.

Houve testes executando previsões do tempo com as mesmas entradas em diferentes hardwares e as previsões divergiram. Se você estiver executando o algoritmo iterativo, uma pequena diferença de arredondamento aqui ou ali poderá resultar em um efeito de borboleta transformando o sol em chuva.

As regras de arredondamento nas normas (IEEE 754, ISO / IEC 10967) foram cuidadosamente pensadas para que algoritmos numéricos se comportem previsíveis com a maior precisão e reproduzam o mesmo resultado todas as vezes. Ao não seguir os algoritmos numéricos padrão projetados para essas regras de arredondamento, os algoritmos iterativos, como as previsões meteorológicas, podem até dar um resultado aleatório.

(e isso não diz algo sobre previsões meteorológicas? :)

— Goswin von Brederlow
fonte

Por outro lado, se o efeito borboleta mudar a luz do sol para a chuva, seus resultados não serão úteis.

— gnasher729

Era uma vez, salvei dados flutuantes em ASCII com dígitos insuficientes. Um cliente queria me mostrar um problema, mas depois de restaurar os dados do arquivo ASCII, o problema desapareceu. Eu disse que algumas coisas não deveriam importar, se o problema dele estava mal condicionado, não havia nada que eu pudesse fazer de qualquer maneira. Ele disse que era problema dele, o meu era fornecer software que permitisse a reprodutibilidade de seus próprios problemas. Ele estava certo.

— aka.nice

É por isso que você deve gerar números de ponto flutuante para salvamentos como hexadecimais usando% a.

— Goswin von Brederlow