Чому має значення точність модуля плаваючої точки?

Більшість діалектів Smalltalk в даний час реалізують наївний неточний плаваючий модуль (fmod / залишок).
Я щойно змінив це, щоб покращити Squeak / Pharo та врешті-решт інші дотримання Smalltalk стандартів (IEEE 754, ISO / IEC 10967), як я вже робив для інших сучасних операцій з плаваючою точкою.

Однак для прийняття цих змін я припускаю, що дотримання стандарту буде недостатньо для переконання моїх однолітків, тому пояснення, в яких обставинах ця точність насправді має значення, мені дуже допоможе. Я не могла знайти собі хорошого прикладу.

Хтось тут знає, чому / коли / де (IOW в якому алгоритмі) матиме значення така точність модуля?

arithmetic floating-point

— aka.nice
джерело

Я думаю, ви можете отримати кращі відповіді на обчислювальну науку, оскільки такі питання важливіші в їхній (під) області. У будь-якому випадку, питання тут є актуальним, і ви повинні дати нашим відповідям за кілька днів до повторної публікації.

— Рафаель

Я бачив код, що покладається на точність fmod / modf, що змусило мене здригнутися, але можливість, що мова може наважитися реалізувати наївний неточний модуль з плаваючою точкою, здається ще страшнішою. Приклад коду: (1) Візьміть решту. (2) Стоп, якщо він дорівнює нулю. (3) Помножте його на 2 та перейдіть до (1). Під час цього процесу можна зробити якусь корисну роботу, але вирішальним моментом є те, що припинення цього процесу покладається на точність залишку та точність множення на 2. Не впевнений, чи варто мені тут дати більш повну відповідь, оскільки обчислювальна наука видається більш доцільною для цього питання.

— Томас Клімпель

Одна здогадка: нормалізація введення тригонометричної функції.

— Пол А. Клейтон

@ThomasKlimpel Мені цікаво, якщо ти знайдеш посилання. Зауважимо, що наївний залишок визначається як (x - ((y / x) усічений * x)) з IEEE-раундом до найближчих парних опій, ми можемо довести, що точнеRem (x, y) == 0 => naiveRem (x, y) == 0. Проблема навпаки - хибний точний поділ на позитивний - як naiveRem (4.0,0.1) == 0.0, який, на жаль, у багатьох випадках відповідає наївним очікуванням!

— aka.nice

@ PaulA.Clayton так, для синуса в градусах, можливо ... Хоча, я гадаю, що наївна рема працює так само добре, як і точне спостереження до прибл. 1e16 градусів тому, що 360 має лише діапазон на 6 біт, і тому, що поділ на 360, здається, ніколи не завершується для попередників кратних 360 ... Для радіанів гідна бібліотека вимагає багатоточної точності, точне зауваження обмежене подвійною точністю дійсно допомогти в такому випадку?

— aka.nice

Зауважте, що неточна реалізація плаваючої точки впливає на погоду.

Були проведені тести, які виконували прогнози погоди з однаковими входами на різних пристроях, і прогнози розходилися. Якщо ви запускаєте ітераційний алгоритм, то невелика різниця округлення тут або там може призвести до того, що ефект метелика змінить сонячне світло на дощ.

Правила округлення стандартів (IEEE 754, ISO / IEC 10967) були ретельно продумані, тому чисельні алгоритми поводяться передбачувано з найбільшою точністю і щоразу відтворюють один і той же результат. Якщо не дотримуватися стандартних чисельних алгоритмів, розроблених для цих правил округлення, вони порушаться, а ітеративні алгоритми, такі як прогнози погоди, можуть навіть дати випадковий результат.

(а чи не говорить це щось про прогнози погоди? :)

— Госвін фон Бредерлоу
джерело

З іншого боку, якщо ефект метелика змінює сонячне світло на дощ, то ваші результати все одно не були корисними.

— gnasher729

Колись я зберігав плаваючі дані в ASCII з недостатньою цифрою. Один клієнт хотів показати мені проблему, але після відновлення даних з файлу ASCII проблема відпала. Я сказав, що декілька ульпів не мають значення, якщо його проблема була погано обумовлена, я нічого не можу зробити. Він сказав, що це його справа, моє забезпечення програмного забезпечення, що дозволяє відтворити власні проблеми. Він мав рацію.

— aka.nice

Тому ви повинні виводити числа з плаваючою комою для збереження у вигляді шістнадцяткових знаків, використовуючи% a.

— Госвін фон Бредерлоу