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

15

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

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

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

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

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

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

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

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

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

user40989
источник
может быть, у вас будут более интересные ответы на math.stackexchange.com
Саймон Бергот
@ Симон Вы можете быть правы, но это определенно междоменный вопрос. Я полагаю, что люди, которые могут ответить, зарегистрированы как для математики, так и для программистов или ни для кого… Давайте немного подождем и посмотрим, найдет ли этот вопрос ответ здесь!
user40989
1
Интервальная арифметика?
SK-logic
2
Использование Эйлера для пропаганды государства не обязательно является злом; Оптимизация тоже не возможна, но вы действительно должны разбить проблему на подзадачи. Численная нестабильность может быть наименьшей из ваших проблем - сходимость к ложному максимуму и проблемы, связанные с жесткостью ODE / PDE, вырисовываются больше, чем это. И да, никогда не используйте одинарную точность :)
Охотник на оленей

Ответы:

6

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

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

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

AProgrammer
источник
3

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

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

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

WPrecht
источник
1

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

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

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

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

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

imel96
источник
Спасибо за ваш ответ, однако я ищу более подробную информацию. У меня очень большие вычисления и я хочу определить их слабые стороны. Я отредактировал вопрос соответственно.
user40989 12.12.13
Я не совсем уверен, какова ваша ситуация, когда вы говорите, что у вас большие вычисления и хотите выявить слабые места. Числовые вычисления по своей природе содержат ошибки, даже одну простую операцию добавления. Таким образом, если ваши большие вычисления не скомпенсированы ошибками, то они в целом должны быть исправлены. Улучшение слабых мест может быть недостаточно хорошим. Если вы теперь «эпсилон» вашей модели с плавающей запятой, простой анализ покажет, насколько велика может быть ошибка, когда они распространяются в ходе длинных вычислений.
imel96
0

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

Инго
источник
Я не хочу избегать числовых ошибок, я хочу найти, какие части вычисления нестабильны. Это похоже на локализацию узких мест при оптимизации скорости. Поэтому я хочу оптимизировать точность и поэтому хочу найти узкие места точности. (Продолжение дробей здесь бесполезно.)
user40989 12.12.13
1
@ user40989, тогда вам определенно нужна интервальная арифметика.
SK-logic