Почему точность модуля с плавающей запятой имеет значение?

Большинство диалектов Smalltalk в настоящее время реализуют наивный неточный плавающий модуль (fmod / remainder).
Я просто изменил это, чтобы улучшить 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 до ближайших четных операций, мы можем доказать, что correctRem (x, y) == 0 => naiveRem (x, y) == 0. Проблема в обратном - ложное точное положительное деление - как naiveRem (4.0,0.1) == 0.0, что, к сожалению, во многих случаях соответствует наивным ожиданиям!

— aka.nice

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

— aka.nice

Обратите внимание, что неточная реализация с плавающей точкой влияет на погоду.

Были тесты, выполняющие прогнозы погоды с одинаковыми входными данными на разных аппаратных средствах, и прогнозы расходились. Если вы используете итеративный алгоритм, то небольшая разница округления может привести к тому, что эффект бабочки превратит солнечный свет в дождь.

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

(и разве это не говорит о прогнозах погоды? :)

— Госвин фон Бредерлоу
источник

С другой стороны, если эффект бабочки меняет солнечный свет на дождь, тогда ваши результаты были бесполезны.

— gnasher729

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

— aka.nice

Вот почему вы должны выводить числа с плавающей запятой для сохранений в шестнадцатеричном формате, используя% a.

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