Как определить нестабильные вычисления с плавающей запятой?

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

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

1. (Предварительная стадия) Сбор физических наблюдений P .

2. Определить начальные параметры моделирования. При этом используется алгоритм оптимизации, при котором мы заходим в пространство параметров и ищем параметры C , чтобы минимизировать некоторую функцию ошибок E (F (C), P) , где F - это некоторое производное количество параметров.

3. Подключите C к двигателю симуляции. Это схема Эйлера EDP, так что на каждом временном шаге мы вычисляем термины, управляющие динамикой (каждый из них представляет собой сложную функцию, потенциально подверженную нестабильности), и снабжаем схему Эйлера этими динамическими терминами для вычисления следующего государство. Это продолжается тысячи раз.

4. В конце моделирования мы вычисляем некоторую функцию Proof (S) конечного состояния S и сравниваем с некоторыми величинами Require (P), выведенными из наблюдаемых величин. Это не формальное доказательство результата, скорее проверка достоверности.

Кроме того, я вижу башню со сложными операциями (вычисление динамических терминов, в схеме Эйлера, в доказательстве ). И хотел бы распознать «плохие детали» и исправить их.

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

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

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

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

Интервальная арифметика была предложена в комментариях. Когда я посмотрел на него, даже самый оголтелый сторонник интервальной арифметики признал, что он хорошо работает с алгоритмами, разработанными для интервальной арифметики, но что переключиться на него без анализа алгоритма и убедиться, что у него не было шаблонов, которые, как известно, не работают должным образом, не будет быть полезным (противники считали, что предварительные условия для интервальной арифметики полезны там, где они слишком ограничены, чтобы представлять практический интерес)

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

NJ Higham. Точность и устойчивость численных алгоритмов. Общество промышленной и прикладной математики, Филадельфия, Пенсильвания, США, второе издание, 2002 г. ISBN 0-89871-521-0

Не зная больше о том, какие типы вычислений, языков и т. Д. Затрудняет дать конкретный ответ. Здесь есть хорошая лекция: http://introcs.cs.princeton.edu/java/91float/, которая может быть немного простой, но это хорошее введение, если вы используете Java.

Как определить нестабильные вычисления с плавающей запятой? Это обычная техника для изучения этого вопроса?

Я думаю, что если вам не нужно показывать статистику ошибок, вам не нужно собирать образцы. То, что вам нужно, это численный анализ , который также относится к предметам численных методов, числовой линейной алгебры и т. Д. И они являются частью компьютерной науки, так что вы также можете получить ответы на некоторые вопросы в cs.stackexchange.

Во всяком случае, в общем программировании большинство проблем легко обнаружить, учитывая некоторое базовое понимание того, как работает плавающая точка, и основных численных методов. Но даже более сложную проблему сегодня «легче» решить благодаря наличию 128-битных операций с плавающей запятой, и даже меньше причин создавать выборки ошибок. Вот несколько примеров проблем, чтобы показать мою точку зрения:

1. использование плавающей запятой для расчета денежных величин.
2. используя плавающую точку для больших чисел.
3. не деление перед другими операциями, когда это возможно. (чтобы сделать значение ближе к 0).
4. длительный расчет без специальной обработки для распространения ошибок.

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

Вы можете избежать числовых ошибок, используя соответствующие типы данных (например, непрерывные дроби). Если вам нужно или вы хотите использовать арифметику с плавающей запятой, вам нужно применить численное ноу-хау, чтобы узнать об ошибках.